Subject: [MMUSIC] video media control draft

From: "Petri K. Koskelainen" <[email-masked]>
Date: Mon, 5 Aug 2002 11:44:42 -0400 (EDT)

Hi,

That draft works only for H.263 codec so it is not
a general solution. Moreover, using SDP a line 
to express options (or group of options and 
complex restrictions) is very difficult.

In the setup phase, you could advertize your
codec capabilities (in SDP), so it
is possible to change options during a call
without further signaling. But I guess
it makes sense to inform also signaling level
about the change (since e.g. bandwidth requirement 
may change considerably if you change options).

Petri

-----------------------------

Hello,

Th draft I mentioned in a previous mail
"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
codec. How do you propose the manage them during a call.

All thoses things are in the stream itself, but, a Video UA need a way
to express them during the initiation of the call and to control them
during the call.

Thanks,

Patrick,

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

---

From: "MONFORT Patrick FTRD/DMI/ISS" <[email-masked]>
Date: Mon, 5 Aug 2002 20:08:03 +0200

Hello,

The draft allows to express H263, H263+ options, but also the format of
the picture (whatever codec you use).

I agree with you saying that simple SDP line is not the best way, but
expressing video capabilities (options, format), without any SDP info
(which is actually the case or else I've missed something) is also very
difficult to do.

To me, the setup phase is one thing, but controlling the media once the
communication is important (someone may want to change the format of the
other's party encoder for example). And yes, if something changes
(option, but once again format), the bandwith may be impacted, and so,
as you mentioned, it makes sense to have signaling to do that.

Patrick,

-----Original Message-----
From: Petri K. Koskelainen [mailto:[email-masked]]
Sent: lundi 5 aout 2002 17:45
To: [email-masked]
Subject: [MMUSIC] video media control draft

Hi,

Petri

Hello,

Thanks,

Patrick,

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 7 Aug 2002 09:19:49 +0300

Joerg and Collin
Thanks for your help, I will advance the work on the video resolution in the
next draft.
As for freeze I had some discussions in Polycom and we think that we can
leave without having a freeze request. We need a solution for fast update
picture and I will be working with Orit on it.
Roni

> From: Joerg Ott [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2002 3:28 PM
> To: Even, Roni
> Cc: Orit Levin; [email-masked]
> Subject: Re: [MMUSIC] video media control draft
> 
> 
> Roni,
> 
> thanks for the reply.  Comments inline.
> 
> > 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.
> 
> You should have other information at hand: the SSRC (in case of a
> translator)
> or the CSRC (in case of a mixer) will be different.
> 
> > 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.
> 
> Again, shouldn't a source change result in a different SSRC/CSRC?
> 
> > 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.
> 
> Ok.  That's a good one.  Thanks for elaborating on this.
> 
> > 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
> 
> Still, I don't think they are in IP as they take different paths with
> unknown
> latency properties.
> 
> > 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.
> 
> SDP does not make sense for the FIR command.  I think enough 
> people have
> argued this and I would like to close this part of the debate 
> and focus
> on alternatives.
> 
> The rest of the SDP extensions you are proposing (picture 
> size, etc.) are
> fine.  We surely had consensus on this.
> 
> > 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.
> 
> I believe have seen statements from videoconferencing folks that did
> not favor the SDP approach.  We are just trying to find a solution
> that fits the spirit of the protocols we are using.
> 
> > As for SIP, are you stirring us to a INFO based solution , 
> I am not aware of
> > other existing solution
> 
> I hope that I did not convey this impression.  I would like 
> to keep you
> away
> from INFO as far as possible.  In my opinion, INFO should be 
> treated as if
> it
> were non-existent.
> 
> Joerg
>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 7 Aug 2002 09:21:08 +0300

Nils,
I think your suggestion makes sense. I will update the draft
Roni

> From: Nils Henrik Lorentzen [mailto:[email-masked]]
> Sent: Tuesday, August 06, 2002 10:35 AM
> To: [email-masked]; Even, Roni
> On Tuesday 06 August 2002 07:59, Even, Roni wrote:
> 
> > Hi Petri,
> > In my draft draft-even-mmusic-video-media-control-00.txt, I have a
> > video-resolution attribute that allow to specify the 
> maximum frame rate
> > supported per resolution.
> 
> A difference between your draft and 
> draft-koskelainen-sdp263-02.txt is that 
> in the latter you may specify resolutions and options per 
> payload type, 
> instead of per media line. I think this is more flexible, and 
> would suit our 
> needs better. Any particular reason for having it per media-line ?
> 
> In your draft it would be a simple change to make it per payload:
> a=video-resolution:<size>
> to
> a=video-resolution: <payload no> <size>
> or possibly
> a=video-resolution: [ PT=<payload no>] <size>
> ie payload no is optional, so if not specified the 
> resolutions would apply to 
> all the payload types on the media line.
> 
> > In the meeting this attribute was accepted for
> > SDP. I could not find the draft mentioned 
> "draft-koskelainen-sdp263-02.txt"
> 
> It expired quite some time ago, but can be found at:
> http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/input/draft-koskelai
> nen-sdp263-02.txt
> 
> Nils Henrik Lorentzen
>

---

From: "Sanjoy Sen" <[email-masked]>
Date: Fri, 16 Aug 2002 14:02:00 -0500

Its meant to be a signal to the endpoint what level of quality the receiver
is willing to receive, so that the transmitter can act accordingly (like
adapt the quantization rate, mark the DS code point etc.). Separate profiles
need to specify these parameter values (for each QoS level) for each
supported codec type. 

-Sanjoy

-----Original Message-----
From: Andreas Kassler [mailto:[email-masked]] 
Sent: Wednesday, August 14, 2002 2:00 AM
To: Even, Roni; Sen, Sanjoy [NGC:B677:EXCH]; 'Nils Henrik Lorentzen';
[email-masked]

Hi,
regarding the visual quality, I was targeting more to variable bitrate
codecs, where you can change
the visual quality (e.g. by changing the quantization) independent from the
frame size and the frame
rate. Of course this may result in a change of the data rate, which may lead
to a renegotiation for
network resources (using RSVP updates or to be defined NSIS signalling).
When you think about constant bitrate codecs I absolutely agree with you
that we need some preferences:
- e.g. frame rate is more important than visual quality
We could use here e.g. some weighting factors and it is up to the codec to
configure itself correctly.
For the "frame rate is more important than visual quality" scenario, we
could have something like 
- frame_rate = 70, visual_quality = 30
For the "frame rate is equally important as visual quality" scenario, we
could have something like 
- frame_rate = 50, visual_quality = 50, and so on.
What do you think?
Regards, Andreas.

----- Original Message ----- 
From: Even,  <mailto:[email-masked]> Roni 
To: 'Andreas Kassler' <mailto:[email-masked]>  ; Sanjoy Sen
<mailto:[email-masked]>  ; Even,
<mailto:[email-masked]> Roni ; 'Nils  <mailto:[email-masked]>
Henrik Lorentzen' ; [email-masked] <mailto:[email-masked]>  
Sent: Wednesday, August 14, 2002 8:35 AM
Subject: RE: [MMUSIC] video media control draft

Hi,
I understand the need for asking for frame rate and frame size since these
are absolute numbers and that is why we have the media control draft and I
will add the support for per payload type.
As for the quality how do you define that in absolute terms, isn't it
something that is an application or codec specific. Is someone using the
quality attribute in SDP and if yes what are the user expectations when he
ask for higher quality comparing to lower quality.How does the encoder use
this parameter, one way to get "high quality" is by reducing the frame rate
or resolution at the same line rate but this can be controlled by those
attributes. At least in this case the receiver can say what he is willing to
scarifies (frame rate or resolution) to get higher quality
Thanks
Roni Even

 
 -----Original Message-----
From: Andreas Kassler [mailto:[email-masked]]
Sent: Tuesday, August 13, 2002 10:49 AM
To: Sanjoy Sen; 'Even, Roni'; 'Nils Henrik Lorentzen'; [email-masked]
Subject: Re: [MMUSIC] video media control draft

Sanjoy et al,
we were also concerned about the expressability of quality attributes that
defines the quality of service at application level for a given video(audio)
stream. 
In draft-guenkova-mmusic-e2enp-sdpng-00.txt we basically have identified a
requirement
to ... introduce (per) codec parametrization attributes like frame-rate,
frame-size, color-
quality-range, overall-quality-range, etc. which should be  uniquely
interpreted by the end-systems.
 
When it comes to negotiation of such attributes with the peer for setting up
quality enhanced
media streams, we propose to specify such parameters on a per codec basis.
The reason is 
that not all codecs support all combinations of such parameters. For example
with a given
hardware, a sender may be able to compress at 25 fps at CIF a H.261 stream
but may
not be able to compress at 25 fps at CIF a MPEG-4 stream due to limited
resources.
 
We propose also to work on these issues within the SDPng context.
 
-Andreas

----- Original Message ----- 
From: Sanjoy Sen <mailto:[email-masked]>  
To: 'Even, Roni' <mailto:[email-masked]>  ; 'Nils Henrik
<mailto:[email-masked]> Lorentzen' ; [email-masked]
<mailto:[email-masked]>  
Sent: Tuesday, August 13, 2002 1:55 AM
Subject: RE: [MMUSIC] video media control draft

I saw this pretty old thread. I do support proposing frame-size on a per
codec (payload-type) basis. I would also like to throw in the requirement
that we need to be able to specify the preferred media qualities (e.g., in a
scale of 0-10) per payload-type (right now SDP defines a quality attribute
per m line). Thoughts?

Does it make sense to encode all these information as part of an "fmtp"
attribute for the payload-type? - e.g., a:fmtp:<PT> res=QCIF/quality=5

-Sanjoy 

> From: Even, Roni [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, August 07, 2002 1:21 AM 
> To: 'Nils Henrik Lorentzen'; [email-masked]; Even, Roni 
> Subject: RE: [MMUSIC] video media control draft 
> 
> 
> Nils, 
> I think your suggestion makes sense. I will update the draft Roni 
> 
> > From: Nils Henrik Lorentzen [mailto:[email-masked]
<mailto:[email-masked]> ] 
> > a=video-resolution:<size> to 
<http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/input/draft-koskelai>  
> > Nils Henrik Lorentzen 
<https://www1.ietf.org/mailman/listinfo/mmusic>