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

From: "Even, Roni" <[email-masked]>
Date: Tue, 8 Jan 2002 09:30:03 +0200

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:[email-masked]]
Sent: Tuesday, January 08, 2002 6:07 AM
To: Even ,Roni
Cc: [email-masked]'
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
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 28 Jan 2002 08:26:04 +0200

Hi Joerg,

About fastupdate in item 2. The reason for fastupdate request from the
receiver is done due to lost synchronization that can happen due to packet
loss or change of received video by the receiver. This is the general
situation and is not dependent on H.261 or H.263 or any specific annex. This
should be a request for action. the indications that I mentioned in item 4
are codec dependent and are left for the sender to decide what to do. I
would like to have PLI and SLI serve as fast update causing an intra frame.
As for item 4 I will send a suggested text during the week
Thanks
Roni

-----Original Message-----
From: Joerg Ott [mailto:[email-masked]]
Sent: Sunday, January 27, 2002 11:49 PM
To: Stephen Casner
Cc: Even ,Roni; [email-masked]'
Subject: Re: [AVT] comments on draft-ietf-avp-rtcp-feedback-01.txt

Roni,

> It was an attempt to fix a problem but it doesn't help.

Yes.  This has been removed from the spec.  Some further explanatory text
regarding feedback collisions will be added.

the
The
> > indications for specific codec are left to the application layer
feedback as
unless
> feedback message of this profile.

Right.  In particular, we cannot mandate a certain behavior in response to a
single message at the sender since, in total, such an action (e.g. fast
update)
may interfere with the goal congestion control.  It needs to be determined
individually per application, session, and sender what the appropriate
actions
would be.  Video coding standards such as H.263 specify how to deal with 
feedback, so there is no need to replicate this here.

Freeze).
> > update and since we have here fast update it is better to have the full

This is not really feedback as the remainder of the document addresses it.
Isn't this a control message sent in the same direction as the video stream
(rather than in the opposite direction) and hence it is something to be
conceptually included in an SR rather than an RR message.  Apparently, there
is some use to this message but in my understanding it does not really
belong to the feedback concept; so where would one put it?  It probably
falls more or less into the category of general control commands that are
synch'ed with a media stream's tinming.

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

If you could provide me with some wording and the necessary bits I'd be
happy to include these in the respective section of the draft.

> > of pli, sli and rpsi are not correct.

Oops, at some time in the past, automated section references got messed up
and I went to manual updating.  Will fix this in the next revision of the
draft (coming soon).

Thanks for pointing this out!

Joerg

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt