Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Video Format (definition of CIF)

62 views
Skip to first unread message

Gary Sullivan

unread,
Apr 4, 1997, 3:00:00 AM4/4/97
to

Regarding the definition of CIF:

The attached prior conversation was passed on to me regarding
the definition of CIF as used in Recommendations H.261 and H.263,
and its relationship to Recommendation 601. My understanding is
that Toerless Eckert is not quite right about the definition of
CIF, but he's pretty close.

Actually, the H.261 and H.263 standards define the square-pixel
area equivalent of the image region covered by a 352x288 CIF
picture to be 384x288, not 375x288. The explanation is a bit
complex, but that is the bottom line.

(I am the Rapporteur in charge of Advanced Video Coding in the
ITU-T. With the help of Associate Rapporteur Keiichi Hibi and
other experts, I am responsible for H.261 and H.263, and thus
I am the keeper of the flame at the heart of the canonical
CIF magic lantern. :-)

Incidentally, you may all be happy to hear that new "H.263+"
optional extensions to H.263 are now being standardized in the ITU
which will allow the use of square-pixel formats and flexible
picture sizes. For further information on that topic, see
ftp://standard.pictel.com/video-site/h263plus


H.261, for example, says there are "352 pels per line, 288 lines"
and that the "picture area covered by these numbers of pels and
lines has an aspect ratio of 4:3" ... (Therefore, each pixel has
width:height aspect ratio of 12:11.)

H.263 says basically the same thing, and it in fact explicitly
says the pixel aspect ratio is 12:11.

The references made in H.261 and H.263 to Recommendation 601 are
*not* used to define the pixel aspect ratio. That is defined
explicitly in H.261 and H.263 themselves.

Thus for a square-pixel image which is 288 lines tall to represent
a CIF image, it should be precisely (352*12)/11 = 384 pixels wide.

We had a discussion of this topic in the ITU about a year ago,
and this was the conclusion of that discussion. I won't go into
the details of the entire history. However, I will point out
that Recommendation 601 is not itself exactly where you would look
to find its pixel aspect ratio either. Recommendation 601 defines
a digital sampling of an analog signal at a certain frequency
(6.75 and 3.375 MHz). Therefore it is the definition of the
underlying analog signal that defines what you will get from the
sampling. The timing of that analog signal differs depending on
whether it is defined for a 625 or 525 line system. The 720 pixel
lines of Recommendation 601 somewhat overscan the actual 4:3 picture
content. In fact the picture content is about 704 pixels wide, and
therefore the pixels are at least very close to being 12:11. In
order to resolve the problem of trying to figure out what *precisely*
was the aspect ratio of a Recommendation 601 pixel, the people who
wrote H.261 and H.263 found that whatever it was, it was very close
to 12:11 and that if we *define* it to be 12:11, it will henceforth
be simpler to deal with than if we just carry it over "normatively"
from Recommendation 601. H.261 and H.263 do contain a "note"
section that say that the CIF sampling has "a simple relationship"
with Recommendation 601, but it does not exactly use Recommendation
601 to define CIF (except for the color space and scaling).

In short, do *not* look in Recommendation 601 to find the
definition of CIF. It is not there. It is in H.261 and H.263.
I believe the only part of the definition of CIF that uses
Recommendation 601 is the definition of the color space and scaling.


Best Wishes,

Gary Sullivan Tel: +1 508-623-4324 Fax: 749-2804 <ga...@pictel.com>
PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810 USA

(The usual disclaimers apply.)

-----------------------------------------------------------
>Return-Path: <rem-conf...@es.net>
>X-Sender: d...@sosfc.adc.sel.sony.com
>Date: Thu, 03 Apr 1997 12:30:48 -0800
>To: Toerless Eckert <Toerles...@Informatik.Uni-Erlangen.de>,
> v...@ee.lbl.gov (Van Jacobson)
>From: Donald Craig <Donald...@adc.sel.sony.com>
>Subject: Re: Video Format
>Cc: rem-...@es.net
>
>This is pretty good, an opportunity to step into a hissing match
>over CIF, of all the disgusting lo-res blind-leading-the-blind
>flickery magic lantern formats there ever was...(Just kidding, guys)
>
>However, I happen to have a copy of ITU-R BT601-4 sitting on a
>colleague's desk (thanks, Hugo), and to clarify Toerless's
>last paragraph (just the 601 bits, I am NOT a CIF expert):
>
> CCIR-601 is officially known these days as ITU-R BT601-4.
> Total samples per line is 858 for 525/60 and 864 for 625/50.
> Active picture samples per line is 720 for both 525/60 and 625/50.
>
> For 525/60 (and drawing on SMPTE 125M-1995), active lines
> are 20 to 263 inclusive for field 1, and 283 to 525 inclusive
> for field 2, giving a vertical picture resolution of 487 lines
> circa 30 times a second. (I don't have the EBU 625 spec handy,
> so I won't pontificate on that exact vertical picture resolution.)
>
>These specifications (particularly the active lines one) are much abused
>in practice, and if you go someplace like Japan you'll get to see nominal
>4:3 aspect ratio happily displayed on your Bazooka TV in 16:9, with many
>little fat people wandering around...
>
>All this, and much, much, more is in a handy book snappily titled:
>"Standards for Advanced Television and High Definition Production with
>Supplemental Standards including Ancillary Audio", ISBN 0-940690-31-4,
>available from: The Society of Motion Picture and Television Engineers
> 595 W. Hartsdale Avenue
> White Plains, New York 10607
>Phone: (914) 761-1100
>Also on the web at: www.smpte.org
>
>cheers,
>Don Craig
>(Definitely not speaking for his current employer, who probably makes
>a CIF something, somewhere...)
>----------------------------------------------------------------------------
>At 06:54 PM 4/2/97 +0200, Toerless Eckert wrote:
>>> > i.e.: a CIF-picture is supposed to transport a video picture
>>> > that has a square-pixel resolution of 375x288. This is often not
>>> > done correctly (i.e.: i think vic and a lot of other
>>> > videoconferencing applications actually transport square
>>> > pixel-video-content in the 352x288 resolution).
>>>
>>> Toerless,
>>>
>>> Where did you obtain this rather amazing & totally incorrect
>>> piece of information? Please read the third paragraph of
>>> section 3.1 of the ITU H.261 standard. It's the one that
>>> starts
>>>
>>> "In the first format (CIF), the luminance sampling structure is
>>> 352 pels per line, 288 lines per picture ..."
>>>
>>> I don't know about "a lot of other videoconferencing applications" but
>>> vic follows the ITU standard *very* closely & its data stream has
>>> successfully interoperated with a number of hardware codecs.
>>
>>I think what i wrote is correct, it's only incomplete without the
>>paragraph that it was written as a reply to:
>>
>>CIF is 352x288 right, but these 352x288 pixels are in intention not
>>square-pixel, which is something that people doing H.261 and other
>>CIF-resolution software on computers often miss. the 352 pixels per
>>line are 1/2 of 704 pixels which is the active-video resolution of
>>CCIR-601 video lines. The total resolution of a CCIR-601 video scanline
>>is 720 pixels.CCIR-601 video is expected to be displayed with an
>>aspect ratio of 4:3, thus the video picture conveyed in 720x576 pixels
>>is not square-pixel. 768x576 would be square-pixel. Thus the square-pixel
>>resolution of 375 in a CIF-picture. Instead of scaling the encoded
>>352 (non-square) video pixels horizontally to be 375, people often already
>>encode square-pixel information into the 352 pixel, which leads to
>>problems when communicating between systems that do (correctly_) not
>interpret
>>the 352 pixels as square-pixel.
>>
>>Anything wrong with this ?
>>
>>Toerless
>>
>>
>
>


Toerless Eckert

unread,
Apr 5, 1997, 3:00:00 AM4/5/97
to

Thanks a lot for the explanation.

Gary Sullivan

unread,
Apr 7, 1997, 3:00:00 AM4/7/97
to


(I got an error message indicating that my previous message
on this topic was refused for rem-conf posting, due to excessive
inclusion of quoted prior text. I am therefore reposting it
without the attached prior text. Apologies to those who might
find some comments to be out of context.)

0 new messages