Subject: RE: [MMUSIC] video media control draft

From: "Even, Roni" <[email-masked]>
Date: Tue, 23 Jul 2002 15:33:00 +0300

Joerg,

The freeze tells the decoder to continue to decode but to not present until
the freeze is released. The release is caused by asking from the encoder a
new full frame, so maybe this is the state change since it releases the
decoder from the released state.
The reasons for the freeze.
1. A mixer can just switch the video without handling of the RTP format, so
the mixer is not looking for the new picture in the RTP payload and may
start sending from the new source before the full picture. This will cause
the decoder to use delta pictures on a previous source information.
2. A mixer that looks at the information and start to send the new source
information only after detecting a full picture may still want to use freeze
in order to let the decoder know that a source switch has occurred, this is
important if the mixer do not change the RTP sequence numbers in order to
keep the sequence numbers from the source. The decoder may think that he
lost packets due to jump in sequence number if he does not know that a
switch has occurred.
3. This is a more advanced one. If we are doing continuous presence based on
taking 4 QCIF images from different source and building a composite CIF
picture, using freeze gives us an option to let the decoder start decoding
after all 4 pictures are available when building the initial picture, the
decoder will get the other full pictures and since he continues to decode
then when the last full QCIF is available, the mixer will release the freeze
and the display will be OK. The same goes for changing one of the QCIF
sources during the conference.

As for your design comment, I do not think that we have a design problem in
H.323. In H.320 the signalling and media are synchronized like in IP. They
run in the same pipe but may have different latencies due to fixed channels
BW, furthermore the fast update and streams are in reverse directions. Also
for fast update the issue is not to have it synchronized with the switch on
the mixer but to have it delivered to the encoder so it will happen sometime
after the switch and free the receiver from the freeze state so it will
start presenting.

As for reliability we are OK with H.245 reliability and I assume will try to
use TCP for videoconferencing due to all reasons mentioned in the SIP
session.

AS for no go in SDP, I do not understand how you reached a consensus, I
think that we are still arguing the issue and will keep our draft alive.

Again, I can give you a rough consensus from the video conferencing people
that RTCP is not a solution for us and since the requirement is coming from
people that are doing video conferencing and have the knowledge you cannot
come and say that you should have the solution on RTCP even if it does not
work. I think that the AVT guys did not agree on a must anyhow since RTCP is
for indication and not for commands. 

As for SIP, are you stirring us to a INFO based solution , I am not aware of
other existing solution

Regards
Roni Even

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 24 Jul 2002 16:46:23 -0400

>the decoder to use delta pictures on a previous source information.

In this case, the mixer is broken. It should change the SSRC on the
outgoing packets (or change the CSRC, depending if it is implemented as an
RTP translator or mixer) which will inform the decoder that a new source is
active, and prevent it using the delta pictures on data from a previous
source.

>lost packets due to jump in sequence number if he does not know that a

The source switch should always be accompanied by a change in either SSRC
or CSRC, so the receiver will always know it has occured. This is the
reason RTP mixers include CSRC information, and why RTP translators
preserve SSRC information.

>sources during the conference.

Again, since the pictures will be identified by CSRC in the mixed RTP
packet, the decoder can perform all these functions without the use of 
freeze requests.

>for indication and not for commands. 

I cannot agree on MUST if the command is passed by the signalling channel
either: an encoder running over IP has to be aware of congestion control.

Colin