Subject: Re: [MMUSIC] RE: Question about draft-levin-mmusic-xml-media-cont rol

From: Colin Perkins <[email-masked]>
Date: Thu, 29 May 2003 20:44:44 -0400

--> "Even, Roni" writes:
>Collin,
>Thanks for the response.
>
>1. About freeze. This is true for H.261 and H.263. The idea of the freeze is
>to tell the decoder to continue decoding but stop display until a freeze
>release arrives. If the full picture arrives in one frame like in H.263 and
>H.261 the MCU can monitor and start sending when he sees the freeze release.
>In H.264 a full picture can span over more then one frame by doing slice
>update, we decided to allow the fast update to span over more then one frame
>as long as the full picture will arrive in less then 3 seconds (better
>congestion behavior). In this case we want the receiver to start displaying
>when the last part has arrived, so the MCU will not know when to start
>sending and the receiver will not know when to start displaying.

Okay, that's a little clearer now. The idea is to avoid the MCU having to
understand the video?

>2. As for the feedback draft, there was no consensus about having a fast
>update request, the opinion was that this is an indication that will allow
>the encoder to decide how to handle it. In the case of MCU video switch the
>encoder does not have enough information to know what is the right behavior
>since he is not aware that the reason was a video switch and not some other
>reason.

I'm not sure it should matter why there is an update request, but if there
is a justification, it would seem appropriate to include the reason in the
RTCP message somehow.

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