RE: [MMUSIC] FWD: I-D ACTION:draft-even-mmusic-video-media-contr ol-00.txt

["Even, Roni" <roni.even@polycom.co.il>]

Jonathan,
The new picture request is used for two different thing.

1. The first one is tied to the freeze picture and is a preferred method to
change the source of the video so that there will not be artifacts. In
multipoint case the conference bridge when it wants to change the video seen
by the others, like in voice actitivated switching, sends a freeze request
to the recivers whose source is about to change and a new picture request to
the new source, the new full picture will release the recievers from their
freeze state. Now the question what is a change in the state of the session.
Is it a change of the codec or is it also a change in codec attribute, for
example a change from recvonly to send or picture orientation. I think that
a change of the stream source is like a change to send.

2. The other case is when a receiver loses synchronization and would like a
new picture in order to synchronize. This is not like a camera control or
device control. A new picture request applies to the media parameters as any
other media parameters to which we have attributes that affect the encoder
directly like ptime, orient, framerate, quality.
 
Thanks
Roni Even
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, June 27, 2002 12:48 AM
> To: Even, Roni
> Cc: 'Joerg Ott'; 'mmusic@ietf.org'; 'avt@ietf.org'
> Subject: Re: [MMUSIC] FWD: I-D 
> ACTION:draft-even-mmusic-video-media-contr ol-00.txt
> 
> 
> inline.
> 
> Even, Roni wrote:
> > Hi Joerg,
> > Thanks for your comments.
> > 
> > 1. About the BNF I will fix it.
> > 
> > 2. I thought of having a section describing the usage in 
> SIP and SAP but
> > noticed that other drafts like offer/answer and simple 
> capabilities do
> > not
> > have section about SIP usage. If you meant that you want to 
> explain how
> > the
> > encoder uses this attribute to select the mode of operation 
> I can add
> > this
> > 
> > 3. About fast update and freeze. 
> > 	3.1 Using RTCP feedback for update was discussed in the last
> > meeting
> > and I agreed with the AVT guys that this should not be there
> > 	3.2 I would like to look at the new picture and freeze picture
> > in
> > the same context as a new codec request. This means that we use
> > signalling
> > to ask for a new codec and I see this feature as the same since I am
> > asking
> > for the same codec but with a new picture. If you want to look at it
> > from
> > the decoder wants a new codec or a new picture. Since 
> changing a codec
> > during a session is working in SAP and in SIP I do not see 
> the problem
> 
> THe problem is that the new picture request, in particular, is not a 
> change in STATE of the session, its a command to send a new 
> picture. The 
> SDP and offer/answer stuff is appropriate where there is a change in 
> state of the session parameters. That is not the case here. I also 
> suspect latency is an issue, since the video is distorted 
> until you get 
> the new intra picture. So it would seem to argue for a media 
> path thing. 
> Latency is generally not an issue for things like codec 
> change and hold.
> 
> The new picture request is a lot like things such as camera controls, 
> which are real-time media stream control activities. I am inclined to 
> argue that the appropriate solution is an e2e control protocol that, 
> like a media stream, is signaled in the SDP. We've argued 
> that the same 
> is true for thigns like floor control.
> 
> Freeze picture request does seem like its a lot like hold. Its a 
> persistent state of the session, and it must be explicitly changed to 
> get off of "freeze". Thus, I think an SDP approach here is fine.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic