[AVT] Application of RFC3497 in pro-MPEG work

Chuck Harrison <cfharr@erols.com> Thu, 10 March 2005 00:43 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09463 for <avt-archive@ietf.org>; Wed, 9 Mar 2005 19:43:37 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Boq-0007ZA-Jb for avt-archive@ietf.org; Wed, 09 Mar 2005 19:46:28 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9BkN-0001M9-Ap; Wed, 09 Mar 2005 19:41:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9BkL-0001M4-5r for avt@megatron.ietf.org; Wed, 09 Mar 2005 19:41:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09175 for <avt@ietf.org>; Wed, 9 Mar 2005 19:41:45 -0500 (EST)
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Bn2-0007Wy-82 for avt@ietf.org; Wed, 09 Mar 2005 19:44:36 -0500
X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication
X-Trace: zyekilkiuUTfsrek0xU9VpcsQZ/HqrOMJrxuwh8zWeE=
Received: from adsl-63-203-119-219.dsl.lsan03.pacbell.net ([63.203.119.219] helo=erols.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1D9BkJ-00061Y-00 for avt@ietf.org; Wed, 09 Mar 2005 19:41:47 -0500
Message-ID: <422F97BF.AA115EC9@erols.com>
Date: Wed, 09 Mar 2005 16:41:35 -0800
From: Chuck Harrison <cfharr@erols.com>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
References: <b2adb62a4d9c49a6ad26ce45661b9ee2@csperkins.org> <874c6249aa2bf9d877a11650c6c5fe79@csperkins.org>
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA09175
Subject: [AVT] Application of RFC3497 in pro-MPEG work
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: quoted-printable

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt