Subject: [AVT] Minutes from Dublin meeting

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Aug 2008 15:22:56 +0100

Minutes from the AVT meeting in Dublin have been uploaded to the  
proceedings site: http://www.ietf.org/proceedings/08jul/minutes/avt.txt

Send any comments to the chairs, please.

Colin
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Tue, 12 Aug 2008 18:56:11 -0400

>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
[email-masked]
"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)

---

From: "Ron Even" <[email-masked]>
Date: Wed, 13 Aug 2008 08:35:30 +0300

Randell,
Thanks for the good summary.

On the parameter sets inband and out of band, my view is that we should add
text on IDR using the text from H.241 that explains the need for parameter
sets. The text should also clarify the reasons for in-band parameter sets
based on the different topologies.

On the level downgrade , I think that you alos summarized in the past that
we need to have better text on the level part of the profile-level
parameter.

The level gives an upper limit on the receive and send capabilities as far
as I underestand the current text. Is this what we is needed. should the
level only give the receive capability for an offer with a=sendrecv

Regards
Roni Even