[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RFC 3984 offer/answer Question
Randell
The text in RFC 3984
Parameters declaring a configuration point are not downgradable,
with the exception of the level part of the "profile-level-id"
parameter. This expresses values a receiver expects to be used
and must be used verbatim on the sender side.
Explains that you can downgrade the level parameter
Roni
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A consensus means that everyone agrees to say collectively what no one
believes individually
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Thursday, August 16, 2007 5:09 PM
> To: Even, Roni
> Cc: Yuval Nissan; ctrobianni at ecotronics.com; avt at ietf.org;
stewe at stewe.org
> Subject: Re: [AVT] RFC 3984 offer/answer Question
>
> "Even, Roni" <roni.even at polycom.co.il> writes:
> >Randell,
> >I can see your point but I would like to see other opinions maybe
from
> >the authors of the text.
>
> Absolutely.
>
> >My view is that most current implementation of offer / answer for
> >unicast has the same approach. (this is based on interoperability
tests
> >between vendors of video conferencing systems)
>
> I suspect that all the implementations you've tested (conferencing
> systems)
> have tested against each other, and they've ended up (perhaps without
even
> realizing it) at a non-compliant implementation. Or perhaps one or
more
> realized the RFC meant the SDP processing would be a royal pain, and
so
> decided to purposely implement something similar but not RFC
compliant.
>
> >The problem here is that the profile-level-id parameter includes
three
> >different parameters.
> >I still think that on the level part of the parameter the comparison
> >should be based on the highest common. I do not believe that the
> >intention here was to fix a specific mode.
>
> Perhaps it wasn't, but that is the result of the text (or more to the
> point, fix a 1<->1 relationship of payload value to level). You can
> support a lot of levels, but the RFC says you have to be able to
> distinguish them by payload value. It ends up wordy in the SDP (VERY
> wordy), but it would work. (It would make support for 3984 above a
low
> level pretty much impossible on UDP SIP, for example, but it's not the
> only
> thing that can do this - see Magnus's 10K SDP example.)
>
> >Since the level parameter is an upper bound and lower levels are
> >included (except for level 1b) it does not make sense to offer a
> >separate media type for each level (there are 15 levels defined), for
> >example if the offerer support level 3 it will need to specify 3,2.2,
> >2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type.
>
> Lower levels are included, but from the registration for
profile-level-id
> in 8.1:
>
> If the profile-level-id parameter is used to
> indicate properties of a NAL unit stream, it
> indicates the profile and level that a decoder
> has to support in order to comply with [1]
when
> it decodes the stream.
>
> (that is declaritive SDP) and for negotiation:
>
> If the profile-level-id parameter is used for
> capability exchange or session setup
procedure,
> it indicates the profile that the codec
> supports and the highest level
> supported for the signaled profile. The
> profile-iop byte indicates whether the codec
> has additional limitations whereby only the
> common subset of the algorithmic features and
> limitations of the profiles signaled with the
> profile-iop byte and of the profile indicated
> by profile_idc is supported by the codec. For
> example, if a codec supports only the common
> subset of the coding tools of the Baseline
> profile and the Main profile at level 2.1 and
> below, the profile-level-id becomes 42E015, in
> which 42 stands for the Baseline profile, E0
> indicates that only the common subset for all
> profiles is supported, and 15 indicates level
> 2.1.
>
> Informative note: Capability exchange and
> session setup procedures should provide
> means to list the capabilities for each
> supported codec profile separately. For
> example, the one-of-N codec selection
> procedure of the SDP Offer/Answer model
can
> be used (section 10.2 of [7]).
>
> 10.2 of RFC 3264 is the "offer inactive with many payloads, get
inactive
> response, reINVITE active with a single payload, get active response".
>
> That (and the "list the capabilities for each supported codec profile
> separately") makes me think that this requirement to have N (or 2*N or
> in theory even more) payloads is intentional, not just poor wording.
>
> >I do not think that this was the intention in offer/answer.
Offer/answer
> >should not be used to fix a specific level.
>
> See above; I'm not sure you're right here. I agree that (unless
there's
> something I'm missing about why they did this) I'd really like to be
> able to have an asymmetric response, but there's no standard (see my
> options a-e in my response to Yuval).
>
> >To make it more complicated, by using the other optional parameters
like
> >max-mbps, max-fs the meaning of the level according to table A.1 in
> >H.264 is changed and the current maximum values supported are based
on
> >the sum of the values from table A.1 and the optional parameters.
>
> Right, though the offer-answer section says that those do not have to
> match in the offer and answer.
>
> >BTW: I do not think that having the same level in the offer and
answer
> >will make the communication symmetric, the encoder on each side can
send
> >any frame size at any macro blocks per second rate that falls within
the
> >specified level (this means frame size and frame rate would not be
the
> >same on each direction).
>
> You're correct it doesn't select actual frame size (in x, y) or frame
> rate.
> (within the limits of the level). However, the assumption of the
writers
> *may* have been that agreeing on a level was important due to some
> algorithmic differences or resource-reservation issues - for example,
an
> offerer who does a lot of streams might not want to have to reserve
enough
> processing power, buffers, etc to decode level 3 if the answerer only
> supports level 1 - but if you let the answerer respond at level 1 to a
> level 3 offer, the offerer doesn't know if they'll receive level 1 or
3.
> (That's totally a guess and likely wrong, but it's an example of why
they
> might have made the decision.)
>
> >If you want to have a specific picture size or frame rate (e.g. CIF
at
> >30 fps) then you will need a different signaling for requesting
specific
> >mode. I mentioned in Chicago that we are working in H.323 on such
> >extensions (requesting a specific mode (picture size and frame rate))
> >and we will have a similar draft for SDP based systems.
>
> Which will be useful when it's available. Our device in reality only
> supports fixed resolutions. It can support others, but it has to
scale
> them to fit on the display, so it's better to avoid that, and scaling
> isn't
> free (horsepower-wise, or artifact-wise).
>
> We may need a 3984-bis, or an explanation why all the conferencing
people
> are doing it wrong or have mis-read the RFC (it's dense reading -
witness
> this discussion. And some people read it and say "that's silly, they
must
> have meant to do it this way..." since they don't know why the rfc
reads
> the way it does - me included.)
>
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> rjesup at wgate.com
> "The fetters imposed on liberty at home have ever been forged out of
the
> weapons
> provided for defence against real, pretended, or imaginary dangers
from
> abroad."
> - James Madison, 4th US president (1751-1836)
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt