Subject: Re: [MMUSIC] draft-even-mmusic-video-media-control-00.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 18 Jul 2002 14:53:29 +0900

But, the key point is, "request" a new intra. In neither case can it
require that a new intra is sent.

Colin

--> "Even, Roni" writes:
>Colin,
>I agree to the RTCP semantic, I do not agree to the meaning of attribute,
>since any attribute that you will use in re-invite in video will have the
>same affect as request for a new intra. And as I said the difference in the
>situation in that the receiver does not inform the sender of QOS problem as
>stated in the RTCP definition in the RTP draft.
>Roni
>
>> -----Original Message-----
>> From: Colin Perkins [mailto:[email-masked]]
>> Sent: Thursday, July 18, 2002 8:44 AM
>> To: Even, Roni
>> Cc: 'Jonathan Rosenberg'; 'Stephen Casner'; [email-masked]
>> Subject: Re: [MMUSIC] draft-even-mmusic-video-media-control-00.txt 
>> 
>> 
>> Roni,
>> 
>> The objection from previous AVT meetings was that the RTCP 
>> indication could
>> not say "MUST send an intra-frame", because there may be 
>> reasons why it is
>> not appropriate for the sender to do so (for example, but not 
>> limited to,
>> congestion on the forward path).  Those reasons exist no 
>> matter how the
>> request is signalled, and using an attribute instead will not 
>> change that.
>> 
>> Colin
>> 
>> 
>> 
>> --> "Even, Roni" writes:
>> >Jonathan,
>> >I agree and that is why I think we need two different 
>> methods. The RTCP is
>> >defined to monitor the quality of service of the received 
>> stream  and that
>> >is why this is an indication, I would not like to use it for 
>> requests and I
>> >think that it was the consensus in the previous IETF AVT 
>> meeting.. What we
>> >want with the attribute, and the text will say it, is that 
>> it is intended to
>> >be used only when the receiver wants to receive a new stream 
>> due to change
>> >of source. We can call the attribute "new stream" so it will 
>> be clearer. As
>> >for abusing the usage this may happen in many aspects of 
>> protocols, if the
>> >text clarifies the usage then any one who does  differently 
>> abuses the
>> >protocol.
>> >The request for a new stream as I view it is like changing 
>> the state since
>> >the receiver wants to get a new stream or switch the current 
>> stream he is
>> >receiving, the same can be said when he asks for new orientation like
>> >changing from portrait to landscape on the current stream.
>> >Thanks
>> >Roni Even
>> >
>> >> -----Original Message-----
>> >> From: Jonathan Rosenberg [mailto:[email-masked]]
>> >> Sent: Thursday, July 18, 2002 7:56 AM
>> >> To: Even, Roni
>> >> Cc: 'Stephen Caner'; [email-masked]
>> >> Subject: Re: [MMUSIC] draft-even-mmusic-video-media-control-00.txt
>> >> 
>> >> 
>> >> 
>> >> 
>> >> Even, Roni wrote:
>> >> > Stephan,
>> >> > The situation is very different.
>> >> > In the first case the receiver lost synchronization, maybe 
>> >> due to loss
>> >> > and
>> >> > want some error correction, it is up to the encoder to 
>> >> decide what to
>> >> > do,
>> >> > for example to reduce the rate or to change reference 
>> >> picture. In the
>> >> > second
>> >> > case the need is for restarting the stream ASAP any other 
>> >> policy from
>> >> > the
>> >> > encoder will not work, it is not a problem indication!!!! 
>> >> 
>> >> And how does the sender KNOW that the receiver has asked for this 
>> >> bandwidth-intensive update because it has actually decided 
>> to change 
>> >> reference picture? What is to stop someone from deciding that 
>> >> they want 
>> >> the maximal picture quality, so that when they have loss an their 
>> >> quality degrades, they send the "force intra-req" message?
>> >> 
>> >> The sends has to make sure it obeys congestion control guidelines, 
>> >> independent of what someone else says.
>> >> 
>> >> -Jonathan R.
>> >> 
>> >> 
>> >> ---
>> >> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>> >> Chief Scientist                             First Floor
>> >> dynamicsoft                                 East Hanover, NJ 07936
>> >> [email-masked]                     FAX:   (973) 952-5050
>> >> http://www.jdrosen.net                      PHONE: (973) 952-5000
>> >> http://www.dynamicsoft.com
>> >> 
>> >
>> >_______________________________________________
>> >mmusic mailing list
>> >[email-masked]
>> >https://www1.ietf.org/mailman/listinfo/mmusic
>> 
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 18 Jul 2002 08:49:52 +0300

Colin,