Subject: [MMUSIC] video media control draft

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

Hi,
The authors of the draft feel that the current situation with the new
picture request is not answering their requirements. The reason we brought
the issue to MMUSIC and not AVT was that we need a signalling solution for
the problem.
RTCP will not work for the following reasons
1. H.323 use signaling path and not RTCP. If we have an H.323 bridge and a
SIP participant will participate through a signalling GW then the H.323
bridge will send a message in the signalling path. The signalling GW will
not be able to forward the request since it is not handling the RTP/RTCP
stream. If we have a SIP conferencing bridge and an H.323 participant
through a signalling GW then the SIP server will send an RTCP message which
is not supported in H.323 EP.
2. We need a reliable channel for the request. RTCP is not a reliable
channel. I assume that with the direction SIP is going we will prefer to use
TCP for signalling in the video conferencing products.
3. About the change of state issue - my understanding of a change of state
is that if a change of state occurs then there may be another message which
will causes a change from the current state. What I am again claiming is
that if we have a typical stream that has only delta pictures (and no full
pictures). This state will stay until a request for change of state asking
for a full picture will arrive. Then a full picture will be sent and delta
pictures which reference the new picture will arrive in the stream. Again
this state remains until a request for a new picture/stream arrives and
again a new stream is started with a new full picture causing a new state of
the stream. It is common in video conferencing from encoder to send one full
picture and from then on just delta pictures until a request for a full
picture arrives

Thanks
Roni Even 

**********************************************
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: Colin Perkins <[email-masked]>
Date: Sun, 21 Jul 2002 22:07:13 +0900

>TCP for signalling in the video conferencing products.

I have difficulty understanding this second requirement: a reliable channel
would seem inappropriate, compared to a timely request that arrives before
the next full picture is naturally sent.

>picture and from then on just delta pictures until a request for a full

Is this not very fragile if packet loss occurs?  Why would you not send a
full picture occasionally, avoiding the fragility and the requirement for
reliable signalling? 

Colin

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 22 Jul 2002 16:12:30 +0100

----- Original Message -----
From: "Colin Perkins" <[email-masked]>

> the next full picture is naturally sent.

Assuming this discussion is still on the same page as I am on.... Its
important that a refresh is reliably signalled sometime after the switch is
made.  Timeliness would be nice, but reliability is more important.  Even a
couple of seconds delay would be better than no signal arriving.

> full picture occasionally, avoiding the fragility and the requirement for

Just in case people on this list are not video codec experts by first
calling (apologies to those that are),... we used to do cyclic
replenishment.  In other words, block 1 was done intra on the 1st frame and
all the rest were done inter, then block 2 was done intra on the 2nd frame
and so on.  This would clear up accumulated noise and transmission errors.
Full intras were sent only on request (or start up) as this involved a
significant increase in bandwidth, and typically involving using coarser
quantisers which meant a visible degradation in the picture.  These
startegies were admittedly for fixed rate ISDN and IP would be more tolerant
to data bursts when a full intra is sent, but even there you want to keep
this bursting to a minimum in case it causes congestion (possibly on your
access link) and packet loss results in more problems than is solves.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

---

From: Colin Perkins <[email-masked]>
Date: Mon, 22 Jul 2002 12:32:08 -0400

>couple of seconds delay would be better than no signal arriving.

Okay, but this doesn't imply sending it via SIP. You could just drop the
request into the next RTCP packet going out (either a regular packet, or
another early feedback packet).

>access link) and packet loss results in more problems than is solves.

Clearly, so. I'm surprised there's not a rolling cyclic replenishment
though, to recover from packet loss, which would also recover if the
full update was lost.

Colin