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

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

>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?

 yes you need to work on 2 lines at the same time

BTW = for 420 we should also restrict the image size to EVEN numbers

>This brings me to another question, that is: How should interlaced YUV 4:2:0
>be transfered?

each field is encoded exactly the same  as a progressive frame
the Field Identification bit does the trick...

> Is interlaced YUV 4:2:0 a common format?

yes! it is the mode of choice for input/output
of standard video codecs at high bit rates/resolutions
and in the TV world!

>How are the shared CbCr values split between the two lines?

they are of "equal importance",
i.e. if you transform YUV420 to (say) RGB the 4 pixels reuse the same value.

(but usualy some filtering is used to smooth out this quantization artefact)

**************

BTW we would rather support a different time stamp for odd and even fields.

regards,

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

                      Ladan Gharai                                                                                                     
                      <[email-masked]>              To:  Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                      
                                                    [email-masked]                                                                       
                      07/11/2002 21:57             cc:                                                                                 
                                                   Subject:   Re: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-01.txt                  
                                                                                                                                       
                                                   Classification:                                                                     

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?

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

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?

 >
 >
 > 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: Fri, 15 Nov 2002 19:32:51 -0500

Philippe:

 > yes you need to work on 2 lines at the same time

therefore the following 4:2:0 video frame:
  line 0:  Y00   Y01  Y02   Y03
              Cb0Cr0     Cb1Cr1
  line 1:  Y10   Y11  Y12   Y13

  line 2:  Y20   Y21  Y22   Y23
              Cb2Cr2     Cb3Cr3
  line 3:  Y30   Y31  Y32   Y33

would be transported progressively as:  
   line 0,1: Y00-Y01-Y10-Y11-Cb0-Cr0 Y02-Y03-Y12-Y13-Cb1-Cr1

   line 2,3: Y20-Y21-Y30-Y31-Cb2-Cr2 Y22-Y23-Y32-Y33-Cb3-Cr3

 > the Field Identification bit does the trick...

and for interlaced transport?

   line 0: Y00-Y01-Cb0-Cr0 Y02-Y03
 
   line 1: Y10-Y11 Y12-Y13-Cb1-Cr1 
 
   line 2: Y20-Y21 Y22-Y23-Cb3-Cr3
 
   line 3: Y30-Y31-Cb2-Cr2 Y32-Y33

 > (but usualy some filtering is used to smooth out this quantization artefact)

yes, we are considering this and will talk about it at the AVT meeting.