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

From: [email-masked]
Date: Wed, 05 Mar 2003 06:27:50 -0500

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-02.txt
	Pages		: 17
	Date		: 2003-3-4
	
This memo specifies a packetization scheme for encapsulating
uncompressed video into a payload format for the Real-time
Transport Protocol, RTP. It supports a range of standard- and
high-definition video formats, including common television
formats such as ITU BT.601, SMPTE 274M and SMPTE 296M.  The
format is designed to be extensible as new video formats are
developed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-uncomp-video-02.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-02.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-02.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: Wed, 05 Mar 2003 10:19:36 -0800

Hi, all,

A few comments on this draft, which is looking very good so far.

---
In uncomp-video-02 we have:

4.3.  Payload Data

Depending on the video format, each RTP packet can include either a
single complete scan line, a single fragment of a scan line, or one
(or
more) complete scan lines plus a fragment of a scan line. [...]

I think there are additional logical possibilities allowed by
the document as it stands: a packet may begin with the tail
fragment of a line, then continue with 0 or more full lines, and
possibly the head fragment of another line.

If the intent is to exclude these possibilities, we need normative
language to say so. If these operational modes are permitted, the
quoted text above is misleading and should be amended.

---
On page 3 of the draft, we have

[...] This payload format
requires that applications using such synchronized ancillary data MUST
deliver it in separate RTP sessions which operate concurrently with
the
video session.  The normal RTP mechanisms SHOULD be used to
synchronize
the media.

I believe the MUST is inappropriate and SHOULD is preferable.

The idea that frame-accurate timecode will be carried as a
parallel RTP session is a laudable but forward-looking conjecture.
IMHO reliable use of this payload format in the near future
will depend on carriage of vertical interval timecode (VITC)
in an unused scan line which is part of the vertical blanking
interval. (This is normal video operational practice, as
mentioned in RFC 2431.)

At the top of page 2 of the draft, we have "...the contents of
horizontal and vertical blanking SHOULD NOT be transported." This
does not bother me as SHOULD NOT language does not prevent me from
carrying VITC when I need it, until the multisession RTP sync
issues get ironed out. On the other hand the MUST language of
page 3 is burdensome.

---
<nitpick>
A minor MUST/SHOULD nit at sec. 4.3 regarding filling to a pgroup
boundary: since a receiver MUST ignore the fill data, it seems
unneccessary that the sender MUST fill with zeroes, specifically.
The sender MUST fill, and SHOULD fill with zeroes.
</nitpick>

---

The MIME and SDP parameters do not include the video frame rate.
There are many plausible scenarios in which it is important
to distinguish alternative frame rates. For example, choosing
the right VOD stream during RTSP setup would need something like
this.

---

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 05 Mar 2003 20:47:37 -0500

Hi,

Thanks for the comments. A couple of replies inline.

>quoted text above is misleading and should be amended.

Those modes are permitted, so I guess we need to clarify the text. Can you
suggest some wording?

>issues get ironed out. On the other hand the MUST language of

I'm still not convinced that an additional timecode is necessary: it should
be derivable from the RTP timestamp and RTCP SR packets. Accordingly if you
wish to synchronize the video to another source, you should use the normal
RTCP method, rather than sending an additional timecode stream (indeed, if
you use RTSP, I _think_ there is already a mapping function between the RTP
timestamp and SMPTE timecode).

>The sender MUST fill, and SHOULD fill with zeroes.

Okay. Is there a reason why zero fill doesn't work?

>the right VOD stream during RTSP setup would need something like

You can use the SDP "a=framerate:" attribute, defined in RFC 2327.

Cheers,
Colin

---

From: Ladan Gharai <[email-masked]>
Date: Fri, 07 Mar 2003 17:10:52 -0500

Hello Chuck, please see some additional comments in line:

thanx,
L.

 > Those modes are permitted, so I guess we need to clarify the text. Can you

 Yes - the draft does not mean to list all possible combinations. 
 Basically anything goes, as long the information in the payload 
 header (offset and scan lines#) can be used to place the data in its
 frame.  Perhaps the wording can be changed to:

 Depending on the video format, each RTP packet can include multiple
 scan lines and fragments of scan lines. 

 > timestamp and SMPTE timecode).

   I guess the big questions in this regard is can the timecode be 
   derived from  RTP timestamp and RTCP SR packets without any loss of
   information?  and how will this impact the interval for sending
   RTCP SR packets?

 > >The MIME and SDP parametersdo not include the video frame rate.