[opendtv] Re: Comparison of H.264 with MPEG-2
- From: "Gary Sullivan" <garysull@xxxxxxxxxxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 22 Sep 2005 13:04:48 -0700
Re Craig's comment:
> There has been some talk of nitpicking, after Bert
> declared that the magic sauce in H.264 is nothing
> more than longer GOPs. I could not let this stand,
> because it is so inaccurate.
Agreeing with Craig here -=20
This notion that the gain in compression effectiveness for using the new
standard instead of MPEG-2 has something to do with stretching out the
GOP length is annoying. That is definitely *NOT* what is going on, and
it is *NOT* how we estimate compression benefits in codec design.
Just about any disciplined codec comparison would compare using equal
GOP lengths, and as far as I know all published comparisons between
AVC/H.264 and MPEG-2 have used equal GOP lengths in both cases. This is
certainly true of the formal "verification tests" done by MPEG and I
believe it is also true of every such test I've seen or participated in
or published.
MPEG-2 can be used with long GOPs too. We wouldn't need a new standard
if that was most of what we needed. We could just use MPEG-2 with
longer GOPs.
I will not dispute that AVC/H.264 can probably achieve more improvement
in compression for P and B pictures than for I pictures. That's
probably true, but that doesn't mean you must stretch out GOP length to
get a major benefit.
If you will permit me to indulge in a little bit of illustrative
algebra, I suggest considering an example case where we have gotten,
hypothetically, about a 60% improvement in the compression capability B
and P pictures (i.e., for what B and P are used for in MPEG-2) and only
half that much benefit for I pictures (hypothetically 30%).
When using MPEG-2, we might estimate that P pictures are compressed
about five times as much as I pictures, and that B pictures are
compressed about twice as much as P pictures on average. Thus, if we
have a half-second GOP length of 15 frames, if we spend x bits on each B
frame then we spend 2x bits on each P frame and 10x bits on each I
frame. In that GOP, there would be ten B frames, four P frames, and one
I frame, so the total number of bits spent on each GOP would be
(10*1+4*2+1*10)*x=3D28*x.
Considering the 60% compression improvement for the B and P frames and
the 30% compression improvement for the I frames, a newer standard would
then hypothetically use (10*1*0.4+4*2*0.4+1*10*0.7)*x =3D 14*x bits.
In other words, in this example there is approximately an overall factor
of 2 improved compression (50% bit rate reduction), without changing the
GOP size and without sacrificing any quality and without assuming that I
frames need the same degree of improvement as non-I frames.
Recalculating the same example for 720p60 video would result, for equal
GOP lengths of a half-second in duration (30 frames in this case), a
reduction from (20*1+9*2+1*10)x =3D 48x bits to 22x bits, or =
approximately
a 54% bit rate reduction for the same quality.
Of course, these are just semi-contrived examples. But the gist of it
has been confirmed in all the test results that I know of.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: opendtv-bounce@xxxxxxxxxxxxx=20
+> [mailto:opendtv-bounce@xxxxxxxxxxxxx] On Behalf Of Manfredi, Albert E
+> Sent: Tuesday, September 20, 2005 10:51 AM
+> To: opendtv@xxxxxxxxxxxxx
+> Subject: [opendtv] Re: Comparison of H.264 with MPEG-2
+>=20
+> Craig Birkmaier wrote:
+>=20
+> > I took the bair from Bert, and decided to look for
+> > some documents that might be helpful in understanding
+> > the improvements in H.264 versus MPEG-2 (H.262).
+> > What follows is an excerpt from a July 2003 paper in
+> > IEEE Transactions, written by several of the people most
+> > involved in both the MPEG-2 and H.264 standardization
+> > processes. The term GOP is never used in this paper.
+> >
+> > www.wwcoms.com/technology/csvt_overview.pdf
+>=20
+> The paper lists the new features provided by AVC. In the
+> first set of 10 bullets, it lists nothing but
+> improvements in motion prediction. I ask you again: what
+> do you think this is for? How do you think the improvement
+> in prediction translates into reducing the bit rate, at
+> equal image quality to another compression algorithm?
+>=20
+> This is a major ingredient in providing the increase in
+> compression. To say that "GOP has nothing to do with it"
+> is to *completely* miss the point.
+>=20
+> The reduced block sizes available with AVC, down to 4 X 4,
+> are likely to have a bigger impact on low resolution
+> images than on SD or HD images. This is just one example
+> of why, GOP aside, the effect of AVC on higher quality
+> images should not be as significant as it is on sub-SD
+> quality images. It makes sense that the more pixels you
+> have in an image, the less the small block sizes will buy
+> you.
+>=20
+> The integer transform does not provide greater tranform
+> accuracy at all, and the article doesn't claim it does
+> either. The integer transform does facilitate COMPUTATION
+> and eliminates errors when doing the inverse transform,
+> however. They call it "exact match inverse transform."
+> But in terms of initial accuracy, it only approximates
+> the DCT.
+>=20
+> Entropy coding improvements will provide an increase in
+> compression. And the various error masking and robustness
+> improvements will mask problems, which will reduce the
+> need for headroom, which will effectively seem like
+> better compression.
+>=20
+> > And for good reason. Such a detail is largely irrelevant,
+> > as both algorithms can be more efficient with longer
+> > GOPs.
+>=20
+> Come now. The point is, you can only extend GOP to a
+> certain point, after which the moving image quality will
+> noticeably degrade. Obviously, the algorithm that allows
+> for longer GOP is the one that provides the greater
+> compression, image quality being equal. Why do you think
+> that long GOPs with AVC were what everyone was after, as
+> reported by Donald during IBC? Because AVC can make good
+> use of longer GOPs, better than MPEG-2 can, and as a
+> result it will achieve the higher compression figures.
+>=20
+> I would think that anyone with a curious mind would WANT
+> to know to what extent GOP plays a part in the large
+> improvements achieved by AVC. For one thing, anyone
+> actually responsible for developing systems that depend
+> on the increased compression will need to accommodate
+> this. You'd feel pretty dumb hiding this information
+> until demo time comes around, eh? I sure would.
+>=20
+> Bert
+>=20
+> =20
+> =20
+> -------------------------------------------------------------
+> ---------
+> You can UNSUBSCRIBE from the OpenDTV list in two ways:
+>=20
+> - Using the UNSUBSCRIBE command in your user configuration=20
+> settings at FreeLists.org=20
+>=20
+> - By sending a message to: opendtv-request@xxxxxxxxxxxxx=20
+> with the word unsubscribe in the subject line.
+>=20
+>=20
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
