[AVT] RFC 3984bis

[Randell Jesup <rjesup at wgate.com>]

>From the minutes of IETF in Dublin:

>   RTP Payload Format for H.264 Video	
>
>   draft-wang-avt-rfc3984bis-01
>
>   https://datatracker.ietf.org/ipr/485
>   https://datatracker.ietf.org/ipr/502
>
>   Ye-Kui Wang presented the revised RTP payload format for H.264 video,
>   outlining the changes to the draft (see slides, and section 17 of the
>   draft) and discussing the open issues.
>
>   An open issue is the changes to the way parameter sets are negotiated.
>   Roni Even noted the changes might affect the backwards compatibility
>   with RFC 3984, but to the best of his knowledge, the affected mechanism
>   is not used, so there's no practical problem. Jonathan Lennox, however,
>   thought this might be used in some streaming applications, and Stephan
>   Wenger noted that 3GPP includes it in MTSI (although he isn't aware of
>   any implementations).

I should note that we (Worldgate) have used sprop-parameter-sets as per
the RFC (or close enough, modulo some of the gray areas).  Earlier versions
used it rather declaratively, but as we've opened up our phones to other
providers and systems we've made (and are making) the code match the spec
much more precisely.  We've had to add all sorts of horrible kludges to
work with existing implementations.

While few if any follow the full RFC 3984 spec with regards to parameter
sets, it seems that everyone ignores a different subset of the spec (and so
interop is really, really painful), and none of the implementations solve
all the problems that sprop-parameter-sets was added (it appears) to solve.

In particular:
* Some implementations ignore packetization-mode and assume 0 for
  everything

  This is just plain horrible.

* Many implementations ignore sprop-parameter-sets, and never send them.

  This can be dealt with by adding rules in rfc 3984bis to specify if/when
  that's allowed, and more importantly what it means (i.e. send parameter
  sets in-band, and do "something" to try to make sure they're received,
  like send them on every IDR).

  Note that there are costs to this (common) usage - extra packets (two per
  IDR typically), and the inability to decode early media (or the early
  part of a call) in the face of a single packet loss, which isn't too
  unusual at the opening of a stream.  Changing parameter sets is tricky as
  well in-call, though doable.

  For added pain, sometimes there isn't a good backchannel if parameter
  sets were lost.  Also note that RFC 5104 only has "please send me an
  IDR-like-thing", there's no way to indicate with that that you're missing
  paramsets (ok, you can do it indirectly with NACK), and that only applies
  to (S)AVPF, not AVP.

* Level downgrade

  This interacts poorly with sprop-parameter-sets (see discussion at the
  previous IETF and on this list.  Also note that constraints can't be
  downgraded (which confusingly means *adding* a constraint), so you can't
  downgrade to level "1a" (and that can cause other confusions).

  (The stream is constrained to the common subset of all the constraints 
  specified - so a constraint byte of 0x80 (baseline constraint only) is
  "higher" (less constrained) than 0xE0 (all three original constraints -
  baseline, main, and I-forget-the-third).  Yes, this is very confusing and
  odd.)

* Implementations that level *upgrade*

  Some are probably ignoring incoming profile-level-id and just sending
  what they're hard-configured to.

  Worse yet, some upgrade in-band after signaling something reasonable -
  i.e. offered level 2.0 with baseline (0x428014), accepted level 1.1
  (0x42800b), then sends in-band parameter sets with level 3.0 and
  different constraints (0x42E01E).  Yikes!  Yes, this is real.

* No one seems to implement the payload-matching rules, certainly not
  all of them.  However, note that I haven't tested everyone by any means. 

* Some (Grandstream I'm talking about you...) mis-parse the BNF and require
  spaces after semicolons (and other errors).

Etc, etc.

>   Jonathan Lennox asked why both sides need to negotiate the use of out-
>   of-band sprop-parameter sets, and wondered if this also forbids in-band 
>   transmission? Ye-Kui clarified that in-band transmission is allowed.
>   Roni Even agreed that this needs clarification in the draft.

Yes, definitely.

-- 
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