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

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

Colin,
In the case of the video switch there is no other way that the encoder can
fix the problem for the receiver without sending a new full picture. Also it
was not a problem with QOS and encoder will still follow the bandwidth
limitation of the session so there is no problem with adding congestion
Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, July 18, 2002 8:53 AM
> To: Even, Roni
> Cc: [email-masked]
> Subject: Re: [MMUSIC] draft-even-mmusic-video-media-control-00.txt 
> 
> 
> 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: Colin Perkins <[email-masked]>
Date: Thu, 18 Jul 2002 15:31:18 +0900

I understand. In some cases, for example if the network is congested, it
may not be possible to fix the problem.

Colin