Re: [AVT] Clarification on Offer Answer usage of H.264 payload format (RFC 3984)

[Randell Jesup <rjesup at wgate.com>]

Someone replied privately; I'd like to make my response public but don't
have feedback from the sender to disclose who it was (though it's not
controversial at all, just politeness)

Note: I wrote this before the AVT meeting today.

Someone wrote (in private email):
>Ow.  Much of this concerns the complexity of the interleaved modes; does
>anyone actually implement them at all, let alone in offer/answer?

Actually, the real problem here is the mixture of the clarification which I
replied to, that level downgrading is allowed, with sprop-parameter-sets.
(And the general complexity, and that some are "I will send" parameters,
and the "match by level/packetization/deint" bit, etc.)

The examples I gave of negotiation problems don't even include any of the
interleaved modes (packetization-mode=2).  They just involve modes 0
(single NAL) and 1 (non-interleaved, with STAPs and FU-A's, etc).

>>This really, really, really needs a rewrite.  It's also so complex, it
>>needs more examples, and if possible an informational(?) algorithm on
>>how to respond. Right now, I'm not certain *anyone* has come even close to
>>100% compliance.  (Maybe one or two have, but...)
>>
>>Existing examples of H.264 traces I've seen show huge variations:
>>
>>*) Many respond without a matching packetization-mode (i.e. respond to an
>>    offer of packetization-mode=1 with no packetization-mode)
>>*) Some respond with a level *higher* than the offer.
>>*) None I've seen include the sprop-parameter-sets from the offerer.
>>*) I haven't seen any that respect parameter-add, though given the previous
>>    point it may not matter.
>>*) Some don't even include profile-level-id at all.
>>*) Some accept packetization-mode=1 in the SDP, but send packetization-mode=0.
>>and there are more problems, that's just the start.  :-(

So, how do we avoid specifying every possible level (and constraint
setting!)?  Plus all the parameter sets for each one.

How important is compatibility with existing implementations?  What's the
most-common actually-implemented-and-works subset?

We could use re-INVITE, but that adds additional layers of exchanges.

It would help to relax the requirement to include the parameter-sets from
the offer in the response, effectively allowing the two directions to be
more different - but that means that if the answer dropped the level, the
offerer would have to send one of the parameter sets from the response,
even though it had offered a higher level and parameter-set.

Perhaps allow level downgrading only if either a) the offerer included an
parameter-set for that level in the reply, or b) the offerer agrees to use
the parameter-set from the response, and if for some reason it can't be
used, the offerer will re-INVITE at the lower level with their own
parameter-set for that level, or c) they agree to in-band paramsets.

Does the parameter-set from the offer *need* to be in the response, if the
levels match?  Parameter sets are what the provider plans to send; if they
were what you plan to receive, then it would make sense.  Just because you
expect/agree to receive a specific parameter set doesn't mean you should
tell the offerer that you might send it.  I'm not sure it hurts, except
that if you want to send a different parameter set you need to make sure
they don't conflict.  This is doable, but requires much more interaction
with the codec and the signalling layer.

-- 
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://www.ietf.org/mailman/listinfo/avt