Subject: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-00.txt

From: [email-masked]
Date: Mon, 21 Oct 2002 08:05:22 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for Uncompressed Video
	Author(s)	: L. Gharai, C. Perkins
	Filename	: draft-ietf-avt-uncomp-video-00.txt
	Pages		: 11
	Date		: 2002-10-18
	
This memo specifies a packetization scheme for encapsulating
uncompressed HDTV as defined by SMPTE 274M and SMPTE 296M into
a payload format for  the Real-Time Transport Protocol (RTP).
SMPTE 274M  and SMPTE 296M  define the analog and digital
representation of HDTV with image formats of 1920x1080  and
1280x720, respectively. The payload has been designed such
that it may scale to future higher resolutions, such as
Digital Cinema.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-uncomp-video-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-uncomp-video-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-uncomp-video-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Chuck Harrison <[email-masked]>
Date: Mon, 21 Oct 2002 20:42:11 -0700

Hi, all,

>         Filename        : draft-ietf-avt-uncomp-video-00.txt

This looks to be a nice clean payload. Time to gum it up with
some bells & whistles! ;-)

There is considerable interest in video standards operating at
12 bits per primary RGB, and some post-production operations use
a fourth "A" of "alpha" channel for keying or compositing.

SMPTE has trial-published a standard 372M for carrying this type
of information at the HDTV 1920x1080 resolution on dual 1.5Gb/s
data channels:
http://www.smpte.org/smpte_store/standards/pdf/s372m.pdf

This RTP payload should make provision for the signal formats
defined in 372M, although a more natural packing based on
8-bit rather than 10-bit words should be considered. Although
372M defines only 1920x1080 formats, similar codings should
be supported at lower and higher resolutions.

When high-resolution motion picture files are exchanged in
professional environments, the "DPX" Digital Picture Exchange
file format SMPTE 268M is commonly used. This is a simple
packed format that provides very wide flexibility in bit
depth and resolution. It would be interesting to mimic this
format in a "streaming" mode under RTP, and this payload
may meet that need with little modification. This is worth 
investigating.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  +1 360 863 8340 (voice)  PDT = GMT-0700
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Chuck Harrison <[email-masked]>
Date: Mon, 21 Oct 2002 21:00:07 -0700

All,

And while we're on the subject, a transparent RTP packetization
for DVI (the digital flatpanel monitor interface) would be
nice...

Chuck

> some bells & whistles! ;-)
[...]

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 22 Oct 2002 12:33:03 +0100 (BST)

> for DVI (the digital flatpanel monitor interface) would be

why?

thanks,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Chuck Harrison <[email-masked]>
Date: Tue, 22 Oct 2002 08:28:33 -0700

Hi, Lloyd

> > for DVI (the digital flatpanel monitor interface) would be
Two reasons:
 (1) A generic ability to provide remote display screens over
      COTS network hardware (e.g. 10GbE) is useful. For example,
      I can imagine a platform-independent "black box" which
      hooks to any device's display port -- e.g. medical
      imager, workstation, etc.
 (2) In a number of commercial high-bandwidth applications,
      manufacturers are looking at DVI as a very low cost
      box-to-box data interface up to 8Gb/s or so. However
      standard DVI is limited to a few meters' length. Again,
      the ability to packetize this and run over merchant
      market 10GbE will provide a platform-independent method
      to extend the usefulness of this type of equipment.

Cheers,
  Chuck

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 22 Oct 2002 16:57:51 +0100 (BST)

>       imager, workstation, etc.

I believe already X11 et al. already do this, so that graphics can
be displayed in a platform-independent way.

L.

---

From: Chuck Harrison <[email-masked]>
Date: Tue, 22 Oct 2002 09:16:13 -0700

Hi, Lloyd

[...]
> be displayed in a platform-independent way.

I was using "platform-independent" in a stronger sense -- e.g.
your HDTV media server or X-ray machine may not be running an
XWindows environment, and it may not be an option for the user
to change that. However, you *can* plug a black box into the
video output jack.

Cheers,
  Chuck