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

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

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!!!! due to congestion
is just a switch of stream that the decoder needs to start decoding. There
was no problem in the transport it is a change in the stream state and that
is why I think it should be an attribute
Roni

> -----Original Message-----
> From: Stephen Casner [mailto:[email-masked]]
> Sent: Thursday, July 18, 2002 6:53 AM
> To: [email-masked]
> Cc: [email-masked]'
> Subject: Re: [MMUSIC] draft-even-mmusic-video-media-control-00.txt
> 
> 
> Roni,
> 
> > The indication is not mandating the sending of the new picture. The
> > situation it addresses is that during the stream flow the 
> receiver lost
> > synchronization and want help from the encoder. The encoder 
> can decide to
> > send a new picture or can start referencing a previous 
> picture that was sent
> > previously. In the new codecs the decoder can have more 
> then one reference
> > picture in storage.
> > The other  case is a request is when the stream change and 
> the receiver
> > cannot use previous information. So it needs a new picture.
> 
> For the first case, do you need to indicate which (one or more)
> reference picture(s) you do have and could use?  For the second case,
> that set is empty.  So you might call these two indications or two
> variations on one indication.
> 
> > I think that RTCP is good for the first case and having an 
> attribute is
> > important for the second case. I think the text should explain the
> > difference cases.
> 
> I don't agree.  In both cases, the receiver is saying "Help, I can't
> display a picture until you send different data."  In both cases, the
> server may have to (implicitly) reply, "Sorry, I can't help you right
> now."  There is no qualitative difference between the two situations.
> 
> As I said before, the argument at the last IETF was about whether the
> document can say the server MUST send a new picture.  As Jonathan said
> in MMUSIC today, using the attribute rather than RTCP does not affect
> that argument.
> 
> We could say something like this:
> 
>     The transmitter MUST implement the capability to send a new
>     intra-coded frame when requested via <the RTCP feedback
>     mechanism>.  However, in some situations, the transmitter may not
>     be able to respond to such a request due to congestion control or
>     other considerations.  The transmitter MUST consider bandwidth
>     limitations in deciding whether or when to respond to such a
>     request.  In particular, the transmitter must prevent a receiver
>     from inducing congestion by repeatedly requesting intra-coded
>     frames.
> 
>                                                         -- Steve
> 
> 
> _______________________________________________
> 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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Jul 2002 13:55:31 +0900

Even, Roni wrote:
> 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