[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level
Jonathan,
I think that only the level can be downgraded not the profile
Roni
-----Original Message-----
From: Jonathan Lennox [mailto:jonathan at vidyo.com]
Sent: Tuesday, May 05, 2009 5:19 PM
To: Elwell, John; Ye-Kui Wang; Roni Even; avt at ietf.org
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level
I agree with John's analysis of Ye-Kui's statement -- trying to do
asymmetric media using separate m= lines isn't very practical for a
number of reasons.
That said, though I think it would be cleaner to have purely
receive-only semantics for profile-level-id, I have trouble imagining
situations for which the current specification is problematic. The
profile-level-id parameter only gives an upper bound on what the
bitstream can contain; it's always valid to send a bitstream that uses a
lower (more constrained) profile and level than what was negotiated.
Thus, I don't see a problem unless an endpoint wants to encode using a
*higher* profile or level than it's able to decode. I suppose this
could happen for pre-encoded video, hardware-assisted encoding, or the
like, but it certainly seems like a more unusual case for bi-directional
media.
--
Jonathan Lennox
Vidyo, Inc
jonathan at vidyo.com
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell at siemens-enterprise.com]
> Sent: Tuesday, May 05, 2009 4:47 AM
> To: Ye-Kui Wang; Roni Even; avt at ietf.org
> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile
level
>
> YK,
>
> If I understand correctly, you would have two m-lines, one a=sendonly
> (on which a lower bandwidth is negotiated, say), and one a=recvonly
(on
> which a higher bandwidth is negotiated, say)? This would really
> complicate things. For example, I think you would need to assign two
> different labels (a=label attribute), because I don't think the use of
> the same label for two m-lines is defined. How would you refer to them
> for floor control purposes? Also you would need to convey two a=crypto
> lines for security descriptions if using SRTP. It would also
complicate
> NAT traversal, e.g., if using ICE, I think you would need to treat
them
> as two separate media.
>
> John
>
>
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of Ye-Kui Wang
> > Sent: 04 May 2009 22:56
> > To: 'Roni Even'; avt at ietf.org
> > Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -
> > Profile level
> >
> > Hi,
> >
> > The current design in the bis draft (as well as in in RFC
> > 3984) does allow negotiation of asymmetric video solutions
> > using SDP offer/answer. What you need to do is just to
> > separate the sending part (a=sendonly) and the receiving part
> > (=recvonly) in the SDP. Therefore, I don't think there is any
> > problem and any need for change in the regard.
> >
> > BR,YK
> >
> >
> > ________________________________
> >
> > From: avt-bounces at ietf.org
> > [mailto:avt-bounces at ietf.org] On Behalf Of Roni Even
> > Sent: Monday, May 04, 2009 5:09 PM
> > To: avt at ietf.org
> > Subject: [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
> >
> >
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt