RE: [AVT] comments on draft-ietf-avp-rtcp-feedback-01.txt

["Even, Roni" <[e-mail]>]

Steve,

About my item number 2. Video fast update are relevant to all video media
and not a specific codec  that is why I think that the sentence should be in
this draft. I  also wanted to make a distinction between feedback
indications and action feedback messages. 
Thanks 
Roni Even

-----Original Message-----
From: Stephen Casner [mailto:[e-mail]]
Sent: Tuesday, January 08, 2002 6:07 AM
To: Even ,Roni
Cc: '[e-mail]'
Subject: Re: [AVT] comments on draft-ietf-avp-rtcp-feedback-01.txt


Roni,

A partial reply to your comments:

> My understanding of the document is that the feedback mechanism is to
allow
> a feedback channel between the decoder and encoder to allow immediate
repair
> of media stream. After reading the document I have the following comments
>
> 1. In section 6.3 the text is "AVPF entities MUST include Generic INFO
> messages along with any payload-specific ones in compound RTCP packets
> (early as well as  regularly scheduled ones). "  This means that if an
> encoder is capable of supporting "nack" it needs to support generic info.
> The capability to support generic INFO is not explained in 4.2. In 6.2 it
> says that "two general purpose transport layer feedback..." but three are
> listed. In 6.2.3 it states that "The Generic INFO packet MUST only be used
> in conjunction with an application-specific feedback message. " which
> contradict the above text in 6.3.

It was resolved at the meeting that Generic INFO will be eliminated.
It was an attempt to fix a problem but it doesn't help.

> 2. The document leaves open the issue of what the senders should do with
the
> feedback. In the video implementations today we see two kind of feedbacks,
> between send and receiver of media, commands and indications. My
> understanding of the nack params (PLI and SLI) is that they are similar to
> the commands, the preferred mode is for them to cause new intra picture or
> MB. This params are for general video media and not for specific codec.
The
> indications for specific codec are left to the application layer feedback
as
> described in section 6.4. I suggest that the last sentence in 4.2 will be
> changed to  "It is up to the recipients whether or not they send feedback
> information and up to the sender(s) to make use of feedback provided
unless
> an action is required by the specific feedback message." The text in 6.3
> will state that PLI and SLI will cause fast updates from the sender. This
> will help with having a consistent response between sender and receiver.

I don't object to your sentence, but the requirement for action is not
specified by this profile, rather by the codec document which defines
the feedback information to be carried with the application-specific
feedback message of this profile.

> 3. In order to be able to use the messages in video switching scenarios we
> need in 6.3 another payload specific message which is PIZ (Picture
Freeze).
> This is needed for completeness. Video switch involves freeze and fast
> update and since we have here fast update it is better to have the full
> support.
>
> 4. For information purpose, we have today in video codec specific
> application the following indications used for resilience support, lost
> picture and lost partial picture for H.263 annex U & W. Not decoded MB for
> H.263 appendix I and video bad MB to let the encoder know that those MBs
> cannot be used for prediction.

An email from Kris Huber today was essentially asking about the same thing.

> 5. In section 4.3 the references to other sections like in the description
> of pli, sli and rpsi are not correct.

							-- Steve

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
http://www1.ietf.org/mailman/listinfo/avt