[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level



From: Ashish Goyal
Sent: Tuesday, May 05, 2009 12:04 AM
To: 'avt at ietf.org'
Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

 

Hi,

   I am leading an effort of sip video vendors under the aegis of IMTC Sip video parity and working on a BCP document to enhance sip video interoperability. In our discussion today there were some concerns around the section 8.2.2 of 3984bis – specifically around the text

 

 “The level part of  "profile-level-id" is downgradable, i.e. the answerer MUST  maintain the same or a lower level or remove the media format  (payload type) completely. “

 

 I am writing this mail in the hope that we can amend the 3984 bis so that we can consider it as a reference – rather than having a conflicting BCP document for video.

 

   The recommendation from the group was to

1)      Consider level parameter as a declaration of receive capabilities and not let it imply the resolution used for transmit

2)      Consider the level parameter as either upgradeable or downgradeable – since it’s really talking about receive capability. The answerer must not transmit a level higher than the offer – but can provide an answer which contains a level higher than the offer. This would allow the offerer to transmit a higher level than it can receive – if it chooses to.

 

  Here is  the issue that we are trying to address by having asymmetric support for level.

 

  One of the use cases which is well supported by some of the leading video implementers is support for asymmetric video resolutions. The use case where this becomes important is when the calls are made from a video softclient  running on  a pc.  Because of asymmetric compute requirements on encode and decode – the video softclients would be able to typically decode much higher resolution – than they are able to encode.  However section 8.2.2  makes this negotiation difficult. 

 

 Here is how the use case is expected to work.

 

  Assume the video device A is able to decode level 3.1 and encode only level 1.1

  B is capable of both decoding and encoding level 3.1.

  A would quote a level of 3.1 in its offer

  B would respond with level 3.1 in the answer

 

  A would send to B video stream at level 1.1 – since A can only encode at level 1.1.

  B would send level 3.1 to A since A can decode upto level 3.1.

 

 

Regards,

Ashish