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

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

Hi,
During the meeting the discussion was about the new picture attribute.
The options were to have it as a new attribute as suggested by the draft or
to use RTCP for requesting the new picture.

We have two uses for new pictures one is an indication and the other is a
request.

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.
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.

**********************************************
Roni Even
Polycom Network Systems
Tel: +972-3-9251200
Mobile: +972-55-481099
Fax: +972-3-9211571
Email: [email-masked]

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

---

From: Stephen Casner <[email-masked]>
Date: Wed, 17 Jul 2002 20:42:42 -0700 (Pacific Daylight Time)

Roni,

> 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.

> important for the second case. I think the text should explain the

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

---

From: Stephen Casner <[email-masked]>
Date: Wed, 17 Jul 2002 20:42:42 -0700 (Pacific Daylight Time)

Roni,

                                                        -- Steve