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

From: [email-masked]
Date: Thu, 7 Nov 2002 13:55:45 +0100

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-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.
ftp://[email-masked]/internet-drafts/draft-ietf-avt-uncomp-video-01.txt

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

---

From: Ladan Gharai <[email-masked]>
Date: Thu, 07 Nov 2002 15:57:28 -0500

Hello Philippe:

Thank you for your input. The format you have defined for  YUV 4:2:0,
certainly makes sense.  I guess, in terms of packetizing and transfering,
there is no other choice but to always transfer 2 adjacent YUV 4:2:0 scan 
lines together? 

This brings me to another question, that is: How should interlaced YUV 4:2:0
be transfered?  Is interlaced YUV 4:2:0 a common format? How are the shared 
CbCr values split between the two lines?

 > for the YUV 420 format we propose:

This is an interesting point. In its current form, the draft is "scan line"
oriented, that is it assumes the basic unit to be packetized is a scan line.
However uncompressed video may also be structured into "macroblocks", particularly,
YUV video (Is planar RGB common at all?).  

To packetize macroblocks the RTP payload header will also ahve to indicate
height and width of the macroblocks. Scan line# and scan offset will still 
be applicable, However Lenght and the F may not be meaningful for macroblocks?

---

From: Chuck Harrison <[email-masked]>
Date: Thu, 07 Nov 2002 16:07:04 -0800

Philippe, all,

[email-masked] wrote:
> [...]
> (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

---

From: "Ivan R. Judson" <[email-masked]>
Date: Thu, 7 Nov 2002 20:14:44 -0600

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,
> 
> 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...
> 
> 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

---

From: Ladan Gharai <[email-masked]>
Date: Fri, 08 Nov 2002 12:40:35 -0500

Ivan -

What is the RFC# (or draft name?) of raw payload format you 
mention?

The other RFC I am aware of the does cover the transport of
uncompressed video is RFC 2431. draft-ietf-avt-uncomp-video-01.txt
is somewhat more general than RFC 2431, from the draft:

11.  Relation to RFC 2431

In comparison with RFC 2431 this memo specifies support for a wider
variety of uncompressed video, in terms of frame size, color subsampling
and sample sizes. While [BT656] can transport up to 4096 scan lines and
2048 pixels per line, our payload type  can support up to 64k scan lines
and pixels per line. Also, RFC 2431 only address 4:2:2 YUV data, while
this memo covers YUV and RGB and most common color subsampling schemes.
Given the variety of video types that we cover, this memo also assumes
out-of-band signaling for sample size and data types (RFC 2431 uses in
band signaling).

Ladan