RE: [MMUSIC] video media control draft
"Sanjoy Sen" <sanjoy@nortelnetworks.com> Fri, 16 August 2002 19:04 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28359 for <mmusic-archive@odin.ietf.org>; Fri, 16 Aug 2002 15:04:29 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22583 for mmusic-archive@odin.ietf.org; Fri, 16 Aug 2002 15:05:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22528; Fri, 16 Aug 2002 15:03:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22497 for <mmusic@optimus.ietf.org>; Fri, 16 Aug 2002 15:03:15 -0400 (EDT)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28280 for <mmusic@ietf.org>; Fri, 16 Aug 2002 15:01:53 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7GJ2GI15153; Fri, 16 Aug 2002 14:02:17 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <KKXYTHK9>; Fri, 16 Aug 2002 14:02:02 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E03A63462@zrc2c012.us.nortel.com>
From: Sanjoy Sen <sanjoy@nortelnetworks.com>
To: 'Andreas Kassler' <kassler@informatik.uni-ulm.de>, "Even, Roni" <roni.even@polycom.co.il>, 'Nils Henrik Lorentzen' <nhl@tandberg.no>, mmusic@ietf.org
Subject: RE: [MMUSIC] video media control draft
Date: Fri, 16 Aug 2002 14:02:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24557.665A2410"
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
X-BeenThere: mmusic@ietf.org
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:kassler@informatik.uni-ulm.de] Sent: Wednesday, August 14, 2002 2:00 AM To: Even, Roni; Sen, Sanjoy [NGC:B677:EXCH]; 'Nils Henrik Lorentzen'; mmusic@ietf.org Subject: Re: [MMUSIC] video media control draft 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:roni.even@polycom.co.il> Roni To: 'Andreas Kassler' <mailto:kassler@informatik.uni-ulm.de> ; Sanjoy Sen <mailto:sanjoy@nortelnetworks.com> ; Even, <mailto:roni.even@polycom.co.il> Roni ; 'Nils <mailto:nhl@tandberg.no> Henrik Lorentzen' ; mmusic@ietf.org <mailto:mmusic@ietf.org> 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:kassler@informatik.uni-ulm.de] Sent: Tuesday, August 13, 2002 10:49 AM To: Sanjoy Sen; 'Even, Roni'; 'Nils Henrik Lorentzen'; mmusic@ietf.org 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:sanjoy@nortelnetworks.com> To: 'Even, Roni' <mailto:roni.even@polycom.co.il> ; 'Nils Henrik <mailto:nhl@tandberg.no> Lorentzen' ; mmusic@ietf.org <mailto:mmusic@ietf.org> 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 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il <mailto:roni.even@polycom.co.il> ] > Sent: Wednesday, August 07, 2002 1:21 AM > To: 'Nils Henrik Lorentzen'; mmusic@ietf.org; Even, Roni > Subject: RE: [MMUSIC] video media control draft > > > Nils, > I think your suggestion makes sense. I will update the draft Roni > > > -----Original Message----- > > From: Nils Henrik Lorentzen [mailto:nhl@tandberg.no <mailto:nhl@tandberg.no> ] > > Sent: Tuesday, August 06, 2002 10:35 AM > > To: mmusic@ietf.org; Even, Roni > > Subject: Re: [MMUSIC] video media control draft > > > > > > 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 <http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/input/draft-koskelai> > > nen-sdp263-02.txt > > > > Nils Henrik Lorentzen > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic <https://www1.ietf.org/mailman/listinfo/mmusic> >
- RE: [MMUSIC] video media control draft Orit Levin
- [MMUSIC] video media control draft Even, Roni
- RE: [MMUSIC] video media control draft Orit Levin
- Re: [MMUSIC] video media control draft Jonathan Rosenberg
- Re: [MMUSIC] video media control draft Colin Perkins
- Re: [MMUSIC] video media control draft Pete Cordell
- Re: [MMUSIC] video media control draft Colin Perkins
- Re: [MMUSIC] video media control draft Joerg Ott
- RE: [MMUSIC] video media control draft Orit Levin
- RE: [MMUSIC] video media control draft Even, Roni
- RE: [MMUSIC] video media control draft MONFORT Patrick FTRD/DMI/ISS
- RE: [MMUSIC] video media control draft Even, Roni
- Re: [MMUSIC] video media control draft Colin Perkins
- Re: [MMUSIC] video media control draft Colin Perkins
- Re: [MMUSIC] video media control draft Colin Perkins
- Re: [MMUSIC] video media control draft Colin Perkins
- RE: [MMUSIC] video media control draft Even, Roni
- Re: [MMUSIC] video media control draft Colin Perkins
- RE: [MMUSIC] video media control draft MONFORT Patrick FTRD/DMI/ISS
- Re: [MMUSIC] video media control draft Colin Perkins
- RE: [MMUSIC] video media control draft Even, Roni
- Re: [MMUSIC] video media control draft Colin Perkins
- RE: [MMUSIC] video media control draft MONFORT Patrick FTRD/DMI/ISS
- [MMUSIC] video media control draft Petri K. Koskelainen
- RE: [MMUSIC] video media control draft MONFORT Patrick FTRD/DMI/ISS
- Re: [MMUSIC] video media control draft Colin Perkins
- Re: [MMUSIC] video media control draft Joerg Ott
- RE: [MMUSIC] video media control draft Even, Roni
- Re: [MMUSIC] video media control draft Nils Henrik Lorentzen
- Re: [MMUSIC] video media control draft Joerg Ott
- RE: [MMUSIC] video media control draft Even, Roni
- RE: [MMUSIC] video media control draft Even, Roni
- Re: [MMUSIC] video media control draft Nils Henrik Lorentzen
- RE: [MMUSIC] video media control draft Eric Burger
- RE: [MMUSIC] video media control draft Sanjoy Sen
- Re: [MMUSIC] video media control draft Andreas Kassler
- Re: [MMUSIC] video media control draft Colin Perkins
- RE: [MMUSIC] video media control draft Even, Roni
- Re: [MMUSIC] video media control draft Andreas Kassler
- RE: [MMUSIC] video media control draft Sanjoy Sen
- Re: [MMUSIC] video media control draft Joerg Ott