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

From: [email-masked]
Date: Thu, 07 Nov 2002 06:20:24 -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-01.txt
	Pages		: 14
	Date		: 2002-11-6
	
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-01.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-01.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-01.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: "Gary Sullivan" <[email-masked]>
Date: Thu, 7 Nov 2002 10:52:04 -0800

The relative ordering of Cb and Cr in this proposal is very unwise.
This is based on macroblocks, and all of the macroblock-based video
compression standards put Cb first and Cr second.  The proposal
has them the other way around.

References: Figure 10 of H.261, Figures 6-10 through 6-12 of
H.262/MPEG-2,
Figure 5 of H.263, etc.  I didn't bother to look it up in MPEG-1,
MPEG-4,
and H.264/AVC, but I'm sure it's the same there too.

It's a judgement call whether to chop 16x16's into 8x8's.  Motion
compensation often works on 16x16 regions in video coding standards.

Best Regards,

Gary Sullivan

+> -----Original Message-----
+> From: [email-masked] 
+> [mailto:[email-masked]] 
+> Sent: Thursday, November 07, 2002 4:56 AM
+> To: [email-masked]; [email-masked]
+> Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt
+> 
+> 
+> 
+> 
+> Hi all,
+> 
+> we think this draft is cool.
+> 
+> for the YUV 420 format we propose:
+> 
+> *********************
+> 
+> For YUV 4:2:0 format video, the Cb and Cr components are horizontally
+> sub-sampled by a factor of four(each Cb and Cr samples corresponds to
+> four Y components). Samples are packed in order 
+> Y00-Y01-Y10-Y11-Cr0-Cb0
+> where Yxy refers to the Luminance sampling on two adjacent 
+> pixel lines
+> and y indicates the line.
+> 
+> The geometry is:
+> 
+> Y00   Y01
+> 
+> Y10   Y11
+> 
+> 
+> If 8 bit samples are used, the pgroup is 6 octets. If 10 bit 
+> samples are used,
+> the pgroup is 15 octets (see tables).
+> 
+> **************************************
+> 
+> 
+> We also propose that a macroblock planar format should be defined.
+> 
+> 
+> The rationale is that 16x16 macroblock  is the basic unit for almost
+> all standard encoding schemes, therefore on the fly encoding could
+> be performed at the receiver with minimal delay.
+> 
+> Planar is when the Luminance and chrominance "planes" are separated.
+> The rational is to save memory access since in most implementations
+> handling the YUV420 format an image is stored in memory as 3 arrays
+> (one for luminance, 2 for each chrominance) (note that this is
+> truely interresting for the 8bit flavor, which is the most 
+> common for 420)
+> 
+> Therefore we propose the following:
+> 
+> the unit of packetization should be a 16x16 macroblock in a 
+> planar order:
+> 
+> Therefore the unit of packetization would be:
+> 256 Luminance values
+> followed by 64 Cr Chrominance values
+> followed by 64 Cb Chrominance values.
+> 
+> For 8 bits values this block size (pgroup) is :384 bytes
+> For 10 bits values this block size (pgroup) is : 480 bytes
+> For 12 bits values this block size (pgroup) is : 576 bytes
+> For 16 bits values this block size (pgroup) is : 768 bytes
+> 
+> 
+> The behavior of the format should otherwise be the same for this
+> as for the "pixel based" mode.
+> 
+> 
+> 
+> 
+> 
+> regards,
+> 
+> 
+> 
+> Philippe Gentric
+> Software Architect
+> Philips MP4Net
+> [email-masked]
+> http://www.mpeg-4.philips.com
+> 
+> 
+>                                                              
+>                                                              
+>              
+>                       Internet-Drafts@                       
+>                                                              
+>              
+>                       ietf.org                     To:  
+> IETF-Announce:;                                              
+>                   
+>                       Sent by:                     cc:  
+> [email-masked]                                                 
+>                   
+>                       [email-masked]              (bcc: 
+> Philippe Gentric/MP4-SUR/CE/PHILIPS)                         
+>                 
+>                       rg                           Subject:  
+>  [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt         
+>              
+>                                                              
+>                                                              
+>              
+>                                                    
+> Classification:                                              
+>                        
+>                       07/11/2002 12:20                       
+>                                                              
+>              
+>                       Please respond                         
+>                                                              
+>              
+>                       to                                     
+>                                                              
+>              
+>                       Internet-Drafts                        
+>                                                              
+>              
+>                                                              
+>                                                              
+>              
+>                                                              
+>                                                              
+>              
+> 
+> 
+> 
+> 
+> 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-01.txt
+>              Pages                         : 14
+>              Date                    : 2002-11-6
+> 
+> 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-vid
+> eo-01.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-01.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-01.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.
+> ftp://[email-masked]/internet-drafts/draft-ietf-avt-u
ncomp-video-01.txt

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

---

From: "Gary Sullivan" <[email-masked]>
Date: Thu, 7 Nov 2002 18:58:36 -0800

And sample aspect ratio.

-G.

+> -----Original Message-----
+> From: Gary Sullivan [mailto:[email-masked]] 
+> Sent: Thursday, November 07, 2002 6:55 PM
+> To: [email-masked]; Chuck Harrison; [email-masked]
+> Cc: [email-masked]; [email-masked]
+> Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt
+> 
+> 
+> This can get kind of elaborate.  Just defining uncompressed video
+> includes specifying at least all of the following:
+> 
+> 1) color primaries (there are several variants of these)
+> 2) white point (D65 or Illuminant C or others)
+> 3) transfer characteristics ("gamma") (there are quite a
+>    few variations of this)
+> 4) matrix coefficients (note that there are several
+>    different standard definitions of YCbCr, for example)
+> 5) scaling (e.g., 8-bit luma normally is scaled down to occupy
+>    235 levels rather than 255)
+> 6) offsets (black is not usually at zero, white not usually at
+>    max representable value, neutral chroma is often 128 rather
+>    than zero, etc.)
+> 7) rounding method
+> 8) bit depth (8/10/12/...)
+> 9) sampling structure (4:4:4, 4:2:2, at least two
+>    distinct variations of 4:2:0, 4:1:1)
+> 10) interlace/progressive
+> 12) timing
+> 
+> And that's just what springs to mind quickly.
+> 
+> Best Regards,
+> 
+> Gary Sullivan
+> 
+> +> -----Original Message-----
+> +> From: Ivan R. Judson [mailto:[email-masked]] 
+> +> Sent: Thursday, November 07, 2002 6:15 PM
+> +> To: 'Chuck Harrison'; [email-masked]
+> +> Cc: [email-masked]; [email-masked]
+> +> Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt
+> +> 
+> +> 
+> +> 
+> +> I was thinking about this on my 2+ hour drive home tonight 
+> +> (lots of time
+> +> to ponder)...
+> +> 
+> +> There is a raw payload format already, so why not 
+> consider augmenting
+> +> the raw payload with a mechanism to specify a data 
+> description, YUV,
+> +> YCbCr, RGB, DVI-D, are all really just different in a) color space
+> +> and/or b) data packing.  Perhaps raw should be extended to support
+> +> different raw (=? Uncompressed) formats?
+> +> 
+> +> Just a thought,
+> +> 
+> +> --Ivan
+> +> 
+> +> ..........
+> +> Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
+> +> Futures Laboratory .~.  630 252 0920
+> +> Argonne National Laboratory .~. 630 252 6424 Fax
+> +>  
+> +> 
+> +> > -----Original Message-----
+> +> > From: [email-masked] [mailto:[email-masked]] On 
+> +> > Behalf Of Chuck Harrison
+> +> > Sent: Thursday, November 07, 2002 6:07 PM
+> +> > To: [email-masked]
+> +> > Cc: [email-masked]; [email-masked]
+> +> > Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt
+> +> > 
+> +> > 
+> +> > Philippe, all,
+> +> > 
+> +> > [email-masked] wrote:
+> +> > > 
+> +> > > Hi all,
+> +> > > 
+> +> > > we think this draft is cool.
+> +> > > 
+> +> > > [...]
+> +> > > Planar is when the Luminance and chrominance "planes" are 
+> +> > separated. 
+> +> > > The rational is to save memory access since in most 
+> +> implementations 
+> +> > > handling the YUV420 format an image is stored in memory 
+> +> as 3 arrays 
+> +> > > (one for luminance, 2 for each chrominance)
+> +> > 
+> +> > Another way to support "planar" formats would be to open 3 
+> +> > parallel monochrome sessions: one for Y, one for Cr, one for 
+> +> > Cb.  Note that the raster resolution on the chroma sessions 
+> +> > would naturally be one-half of the luma session.
+> +> > 
+> +> > You'd probably packetize the Y on 16-pixel pgroups and the 
+> +> > CrCb on 8-pixel pgroups to keep each line of a macroblock 
+> +> > together in partial ALF style...
+> +> > 
+> +> > I haven't thought much about the plusses and minuses of this 
+> +> > planar approach but I thought I'd toss it out there for 
+> discussion.
+> +> > 
+> +> > BTW has anybody looked at the LBL "Visipult" UDP 
+> +> > packetization that they used to win the SC2001 network 
+> +> > bandwidth challenge? It has some similarities to the 
+> +> > uncompressed-video draft. (And stay tuned for SC2002 next 
+> +> > week in Baltimore!)
+> +> > 
+> +> > Cheers,
+> +> >   Chuck
+> +> > _______________________________________________
+> +> > Audio/Video Transport Working Group
+> +> > [email-masked]
+> +> > https://www1.ietf.org/mailman/listinfo/avt
+> +> > 
+> +> 
+> +> _______________________________________________
+> +> Audio/Video Transport Working Group
+> +> [email-masked]
+> +> https://www1.ietf.org/mailman/listinfo/avt
+> +> 
+> _______________________________________________
+> Audio/Video Transport Working Group
+> [email-masked]
+> https://www1.ietf.org/mailman/listinfo/avt
+> 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Fri, 8 Nov 2002 10:31:20 +0100

OOPS ! (hi Gary)

so the correct order should be:

Y00-Y01-Y10-Y11-Cb0-Cr0

right ?

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.mpeg-4.philips.com

                      "Gary Sullivan"                                                                                                  
                      <garysull@micros             To:  Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                      
                      oft.com>                      <[email-masked]>                                                                     
                                                    <[email-masked]>                                                                    
                      07/11/2002 19:52             cc:  "Stephen Estrop" <[email-masked]>                                      
                                                   Subject:   RE: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt                  
                                                                                                                                       
                                                   Classification:                                                                     

Best Regards,

Gary Sullivan