Subject: [AVT] Slides for IETF62 Monday

From: Colin Perkins <[email-masked]>
Date: Mon, 7 Mar 2005 08:43:23 -0600

The presentation materials which will be used in AVT today can be 
retrieved from http://csperkins.org/misc/ietf62-avt-day1.zip

These will migrate to the IETF proceedings page after the meeting.

Colin

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Mar 2005 10:41:36 -0600

> These will migrate to the IETF proceedings page after the meeting.

Slides for the session this afternoon can be found at
http://csperkins.org/misc/ietf62-avt-day2.zip

Colin

---

From: Chuck Harrison <[email-masked]>
Date: Wed, 09 Mar 2005 16:41:35 -0800

Greetings,

FYI - RFC3497, RTP Payload Format for SMPTE 292M Video - has been
cited in a commercial Code of Practice issued by the Pro-MPEG forum.

Pro-MPEG Code of Practice #4 release 1, July 2004, Transmission of
High Bit Rate Studio Streams over IP Networks is available at
http://www.pro-mpeg.org/publications/pdf/HBRSS-on-IP-CoP4-r1.pdf .

This application deviates somewhat from what we envisioned when the
RFC was written here. For example, its main application is for
270Mbit/sec standard definition video rather than 1.485Gbit/sec
high definition video. These two video standards are structured
so similarly that this works.

---- begin included text ----

The RTP format proposed is that from RFC3497 with the following 
extensions:
• For Standard Definition, the RTP timestamps shall be derived
   from a 27MHz clock locked to the input, not from the 148.5MHz
   clock required by RFC3497.
• For other video systems the RTP timestamp shall be the word
   clock rate of the video system.
• To assist with picture concealment in the event of lost packets,
   the data in a packet shall only come from one line1 of video.
   As an implication of this the EAV field will always occur
   at the start of a packet.
• In addition to this, there shall be a custom RTP header
   extension to assist with defining where in a line a particular
   packet starts which equipment which complies with this code
   of practice shall adopt.
---- end included text ----

The 4th bullet specifies an RFC3550 header extension.

Persons implementing RFC3497 may wish to test to be sure that
packets carrying this header extension don't break their
applications.

Peace,
  Chuck Harrison

---

From: Stephen Casner <[email-masked]>
Date: Wed, 9 Mar 2005 20:04:05 -0800 (PST)

Chuck,

> cited in a commercial Code of Practice issued by the Pro-MPEG forum.

Thanks for this notice.  It is pleasing to see our work used, but I
am concerned about one aspect of the adaptation:

>  - For Standard Definition, the RTP timestamps shall be derived

This is not really a problem since the clock rate can be specified in
SDP.  We have had other examples of payload formats where new
applications were identified that needed a clock rate not anticipated
in the payload format specification.

>  - For other video systems the RTP timestamp shall be the word

Ditto.

>  - To assist with picture concealment in the event of lost packets,

Application profiling, again not a problem.

>  - In addition to this, there shall be a custom RTP header

This is unfortunate.  If the additional information is really needed,
then a new payload format should have been defined to add this
information to the payload header.

                                                        -- Steve