Re: [MMUSIC] video media control draft

["Andreas Kassler" <[e-mail]>]

RE: [MMUSIC] video media control draftHi,
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, Roni 
  To: 'Andreas Kassler' ; Sanjoy Sen ; Even, Roni ; 'Nils Henrik Lorentzen' ; [e-mail] 
  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:[e-mail]]
  Sent: Tuesday, August 13, 2002 10:49 AM
  To: Sanjoy Sen; 'Even, Roni'; 'Nils Henrik Lorentzen'; [e-mail]
  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 
      To: 'Even, Roni' ; 'Nils Henrik Lorentzen' ; [e-mail] 
      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:[e-mail]] 
      > Sent: Wednesday, August 07, 2002 1:21 AM 
      > To: 'Nils Henrik Lorentzen'; [e-mail]; 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:[e-mail]] 
      > > Sent: Tuesday, August 06, 2002 10:35 AM 
      > > To: [e-mail]; 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 
      > > nen-sdp263-02.txt 
      > > 
      > > Nils Henrik Lorentzen 
      > > 
      > 
      > _______________________________________________ 
      > mmusic mailing list 
      > [e-mail] 
      > https://www1.ietf.org/mailman/listinfo/mmusic 
      >