screenshots of h.263/h.263 and MPEG/MPEG encodes

[iago]

Movie: Fight Club (2hr-19min) NTSC1
640*272 / neutral bicubic
external curve compression with statsreader 1.1
lumi masking in both passes
quantizers capped: 2-4/2-8
payback proportionally
credits: 20quant
video size: 750000kb

h.263/h.263 average quantizer: 2.972
MPEG/MPEG average quantizer: 3.114

screenshots are attached below.

best regards,
iago

[HarryM]

Screenshots? Where?

[iago]

Screenshots are attached to the above post. I think they haven't been approved yet ;).

iago

[Acaila]

As always H.263 gives a more smoothed picture. I know this helps in keeping the noise down (although it doesn't seem to help one bit against ringing noise), but it also (slightly) smooths the details. One of the reasons that XviD is so great is because of the amount of detail it posesses. Now with the latest incarnation of modulated quants the highest possible quality that can be attained (quant 2, or 1 if you're insane :)) will have less detail compared to the old method.
Noise can be smoothed with filters, detail that is lost is lost forever.

So my vote goes for the old way, MPEG matrix for quant 1-3, H.263 for quants >3.

[Koepi]

Acaila,

try it at least and stop simply telling everybody that it sucks and is bad. My last matrix h263/h263 rip has an amazing quality and plenty of details.

MPEG quant introduces noise and thus the details are the same, but you _think_ you see more. Try that with the ffdshow noise option, you'll instantly think you're watching something MPEG quantized ;)

Koepi

[iago]

Hi everyone,

Well, I didn't want to make any comments in the beginning, but I must admit that actually I liked "both encodes" a lot when I watched them, and I really couldn't make a judgement on which one is better, so I'm only reading the comments! ;)

Maybe, there "is" a difference that my poor eyes can't tell atm after so many tries and watching hours ;), and I have to check again when I offer my weary eyes a good sleep :).

ciao,
best regards to all,
iago

[Blight]

iago:
I think doing low-quality jpeg as comparison is the real problem, you should use PNG so that it would be lossy. Sure, it'll be big, but it'll show us images without details lost to JPEG.

And in my personal opinion, h263 looks better, it has better color gradients, which is one of the first things you lose to lossy compression.

[iago]

@Blight

you should use PNG so that it would be lossy Sorry but I couldn't understand it. Do you mean "use PNG so that it WOULDN'T be lossy" ?


EDIT: Yes, I see that's what Blight means. So, some clean-up was necessary in the thread to remove the unnecessary comments and explanations "by me" ;) regarding jpeg-png, together with the previous jpeg screenshots. And it's done! :).

best regards,
iago

[Koepi]

I hate to write this...

I agree with blight, for a proper comparison you need something lossless :-/
PNG would be the choice as it's opensource and patent-free (damn, first GIF, now JPEG is on the line...)

At least for our comaprisons here it's necessary if you don't want to show bugs like displaced macroblocks, inverted or miscolored MBs,... we are talking about details that get DCT'ed away by jpeg :-/

I'm really appreciating all your tests, iago! And not just from you, from everyone else too, of course!

But please, for the next time let's agree on some lossless format for comparisons when the details are effected. I don't care if we have 20 frames or 3 - in fact, looking at three "mostly obvious" cases takes less time than looking at 20 pictures where you have to guess what's wrong or ok due to the compression ;) ).

This is not meant bad or offensive. Just constructive critics!

I hope nobody feels bad now, this isn't my intention.

Best regards,

prost, serefe, cheers, slante, santé, salute, nastrovje, ...

Koepi

[iago]

@Koepi and Blight

Well, of course OK, I can't see any point here to take offense.

I'll send some screenshots again from both encodes asap, this time in PNG format. I guess this will solve the problem and provide a better comparison.

regards,
iago

[gft]

I'm quite sure that no matter what compression level you set PNG to, it is still lossless.

-gft

[iago]

Hello again,

Screenshots with PNG (compression level: 0) are attached below ;).

@Koepi,

Maybe it's better to delete the previous JPG screenshots attachment.

best regards,
iago


EDIT: To: Blight and Koepi: Thanks for the warning and clearing this issue up. From now on, screenshots will be in PNG format ;).

[HarryM]

Originally posted by Blight
And in my personal opinion, h263 looks better, it has better color gradients, which is one of the first things you lose to lossy compression.

I don't agree fully...

Mpeg quant has better color gradients. Colors appear better, liverier, more or less really (naturally).

H263 quant has a little vomit colors, ehmmm...



I tested it on group of ignorants (anyway greenhorns in divx/xvid problems, total users). Everybady said, that are very difficult resolve (tested on two synchronized monitors, at the first h263 plays, at the second mpeg plays).

But 6 of 8 finally said, that mpeg quant (at quant=2) is much BETTER for looking.

[Blight]

You can't test on 2 monitors (no matter how much you tune it, no two monitors are alike)...

Use a program like ACDSee, have a 100% black background, DON'T stretch the video.

In ACDSee, you can use page up/down to switch between the images with no flicker. Best way to see differences.

I also recommend testing a monitor using Apature-Grill technology and not any of those disgusting Net/Shadow Masking monitors which blue the pixel outlines and distory the image.

[Blight]

ok, after viewing the PNG images, I must say the MPEG look better.

They had far more defined edges. This is most noticable in image "96436", look at Ed Norton's nose, look at the shadow, see how the tip of the top area of the shadow is much more defined in the MPEG version.

But what I think we really should have in this comparison, is not only the MPEG and H263 images, but also the SOURCE image, so we can compare to that...

And BTW, you can use PNG compression... PNG is lossless. But since you zipped it, I don't think it matters as much. Although RAR does have a better RGB compressor.

[Didée]

Originally posted by Blight
[...] Although RAR does have a better RGB compressor.

It depends, Blight.
Lately I made some HUGE test. I´ve scanned all notes of our German D-Mark, before the Euro took all over. I scanned with 1600 dpi, the raw scans were about ~2 GB total.
Then I compared PNG-compression vs. RAR 3.0 RGB-compression. PNG was done with IrfanView, from my experience it - somehow - reaches the best PNG compression at all.

Out came the following:
Sometimes RAR achieved better compression.
Sometimes PNG achieved better compression.

So, in the end, both methods are equal.

---------------------------------------
OT remark:
If someone is interested in HiQ-scans of D-Mark notes ...

[oddball]

I definitely prefer the MPEG samples too. More detailed. However I am not sure how this would look on playback so it's really not a fair comparison.

[iago]

@oddball

On playback, using Nic's decoder filter strength 4 (with no dering - full deblock), both encodes look pretty good imho, h.263/h.263 only a bit softer.

regards,
iago

[R3g]

Just one thought : instead of discussing which quant is better, isn't it time for starting designing new, high-quality-a-bit-smooth-but-still-keeping-details custom quant matrixes ?

[Neo Neko]

Originally posted by gft
I'm quite sure that no matter what compression level you set PNG to, it is still lossless.

-gft

Yes PNG uses Zlib compression libraries. Basically it is the same thing as ZIP minus one copyrighted compression algorythm.

Originally posted by Didée
PNG was done with IrfanView, from my experience it - somehow - reaches the best PNG compression at all.

IrfanView is good. I tend to use Xnview. It also does good PNG compression. Now we just need to get the IE users turned on to MNG and JNG. ;)

For toons h263 and for live I tend to do modulated or h263 for TV caps.

[-h]

Off-topic diatribe on PNG.

I don't like it. For some reason they chose a pretty poor set of compression techniques - it's now quite outdated, but we seem stuck with it for a long time yet.

Doing away with GIF was a noble goal, but I'd be much happier if they chose methods that were anywhere near best-of-breed at the time. Even huffyuv beats PNG on most natural pictures.

-h

[Emp3r0r]

i did some tests with h263 and mpeg and compared the two first pass files.

the h.263 file was 990megs
the mpeg file was 1152megs

first of all these encodes only looked decent when lowering my rez to 640x480 since the movie was encoded at 640x272 this required no overlay resizing.

after resizing the differences between mpeg and h.263 are not worth the differences in compression. imho h.263 wins for delivering on a good looking encode that was over 150 megs smaller yet retained great quality and with minimal (if noticable at all during playback) details lost. i personally prefer h.263 with a neutral bicubic resizing for best tradeoff between compression and details. just make sure you don't have any overlay resizing because nvidia makes all my encodes look like ass if I allow it to overlay resize.

[soujir0u]

How to disable overlay resizing?

[Blight]

-h (off topic):

HuffYUV compresses in YUV most of the time (unless you supply it with RGB source and haven't selected RGB to YUV).

If PNG saved the RGB data in YUV it would be smaller, but they don't as RGB -> YUV is lossy.

[iago]

Hello everybody,

Hoping that Fight Club h263/h263 - MPEG/MPEG screenshots is found useful and provided some sort of comparison between the two quantization types used in two encodes with the exact same other parameters, I'll prepare and post screenshots from Matrix h263/h263 and MPEG/MPEG encodes done with the exact same parameters again.

best regards,
iago

[iago]

I was just about to post the screenshots but I realized that maximum attachment size is only 204800 bytes, which means I can't send the two separate screenshots of even 1 frame in PNG format ;).

Any solution? :)

regards,
iago

EDIT: Well, of course it's due to band-width limitations. I guess I'll start a webpage to host the screenshots for comparison, though I don't know when ;). Thanks.

[unplugged]

Originally posted by Acaila
As always H.263 gives a more smoothed picture. I know this helps in keeping the noise down (although it doesn't seem to help one bit against ringing noise), but it also (slightly) smooths the details. One of the reasons that XviD is so great is because of the amount of detail it posesses. Now with the latest incarnation of modulated quants the highest possible quality that can be attained (quant 2, or 1 if you're insane :)) will have less detail compared to the old method.
Noise can be smoothed with filters, detail that is lost is lost forever.

So my vote goes for the old way, MPEG matrix for quant 1-3, H.263 for quants >3.
I agree with Acalia.

About H.263, one constant thing that I have noticed many times is that with certain contents does a bad job by having tendency to "join" adjacent pixels "assuming" equal tonality, resultant to a bit flat output.

Specific contents suffer MUCH by this.

When the source video has low contrast shades and is overall pretty clean (few noticeable noise) H.263 quantizer totally washes the output, and if the source had worse color contrast or dynamics it make the final job even worser.

Recently, I haven't tested how *modulated* method do the job (after improvements to XviD code), but time ago haven't loved how it performed, I easily saw the pixel fluctuation due to repeated jumps from H.263 to MPEG and viceversa.

IMHO, H.263 flaw(s) is hardly noticeable with high contrast and/or medium noise content, plus in these cases the better compression results are welcome (as opposite to MPEG quant).

[unplugged]

Originally posted by Koepi
MPEG quant introduces noise and thus the details are the same, but you _think_ you see more.
The detail difference is often noticeable, especially over light shades and from my VirtualDub A B C comparisons the *artifical* detail (symptom of MPEG quant) is only a part of the real maintained detail, using MPEG.

But, to be honest, must be said that the importance of MPEG or H.263 much depends by nature of content.

[Koepi]

Originally posted by unplugged
But, to be honest, must be said that the importance of MPEG or H.263 much depends by nature of content.

I think we can agree on this!

Best regards,
Koepi

[oscarBravo]

waaay OT, but...
Originally posted by Koepi
prost, serefe, cheers, slante, santé, salute, nastrovje, ...

Um, it's sláinte. (Assuming you meant the Irish toast.)

[Koepi]

Thanks for clearing that up :)))

and again in-topic:
XviD-03092002-1:
- Updated to Statsreader 1.4.
- Foxers 2nd pass external/credits fix

No must-download, just wanted to mention it anywhere... ;)

Regards,
Koepi

[soujir0u]

Yeah, I have noticed that some sources look perfectly fine with H263 whereas some look horrible compared to MPEG quantizers. I guess heavily-smoothed sources such as cartoons, anime, etc look pretty OK with H263 (not all though). With the test encodes I did, noisy material looked better with MPEG quantizer.

[iago]

Tadaaa! ;)

Finally done!. Those who are interested can see the screenshots of Matrix h.263/h.263 and MPEG/MPEG encodes visiting: http://www22.brinkster.com/raindog/

Beware! It may knock down your patience! ;) (images are in compressed PNG format...)

best regards,
iago

EDIT: Pahh! The above site also suffers from the same problem I guess :(. Bandwidth-limitation! Well, that's it for now...

[Emp3r0r]

@iago: i'm willing to host your images on fast server. i must warn you though that this computer is supposed to be moved to another office (yet they said that was going to happen weeks ago) so I'm no so sure how permanant the home would be.

regards, Emp

[iago]

Originally posted by Emp3r0r
@iago: i'm willing to host your images on fast server. i must warn you though that this computer is supposed to be moved to another office (yet they said that was going to happen weeks ago) so I'm no so sure how permanant the home would be.

regards, Emp @Emp3r0r
Thanks a lot for your kindness ;). Why not, if it wouldn't be a problem for you. And never mind, let it survive as long as it can. (After all, under the circumstances, I guess it is a "must" to move it to another server.) So, how? ;)

thanks for your kind offer,
iago

EDIT: Waiting for your reply if it looks possible for you.

[trbarry]

When I first heard of the difference between mpeg and H263 I compressed a couple clips both ways using quant 2. From this I first (wrongly?) decided that H263 compresses better. But what I think actually happens is that h263 at quant 2 is more like mpeg quant at 2.5 (or some number). This is because of the larger numbers toward the edge of the quant tables in h263.

So more recently I've pretty much decided that if I have a very detailed very clean clip and I'm willing to spend a lot of bits encoding it (close to quant 2, say for HDTV) then I'll use the mpeg quant.

Otherwise I'll use h263 or modulated. Once you have to start sacrificing any detail at all for compression then I think maybe with H263 it does it better, even though an HDTV comparison at quant 2 would show just the opposite.

Or at least this summarizes my current state of confusion.

- Tom

[unplugged]

Taking in account quality at the most wanted quantizers, 2 and 3

Roughly, H.263 is ID of DivX like, try to make comparisons with DivX 4-5 you can see that at similar quant. levels the results are near to identical. :)
MPEG is "the solution" if you have enough bitrate and don't want the typical annoying behavior of MPEG4 codecs that tends to join similar pixels/areas (that will become totally flatten).

(not happen with DivX 3.2, but it has other serious problem... motion encoding really sux!)

[Neo Neko]

I could not resist since I am a PNG fan. Sorry for the OT

Originally posted by -h
Off-topic diatribe on PNG.

I don't like it. For some reason they chose a pretty poor set of compression techniques - it's now quite outdated, but we seem stuck with it for a long time yet.

Doing away with GIF was a noble goal, but I'd be much happier if they chose methods that were anywhere near best-of-breed at the time. Even huffyuv beats PNG on most natural pictures.

-h

They chose the best compression at the time -h. You know when PNG was rattified right? To put it this way the W3C made it a web standard back in 1996. And it takes a few years to get to that point. PNG came into being back in 1994 or so. Back when we were watching those spiffy new 320x240 Mpeg1 videos on our 60Mhz Pentiums or possibly Acorn or Amiga. At the time it was best in show but no one was courting it. 1998 saw the first major support. Nearly 4 years later. And only now do we have the first browser to fully and properly support it. Namely Mozilla. Internet Explorer is waaaaaaay behind unless you are on a Mac. If you have the right tools and software PNG is kick arse. Like I said check out JNG and MNG. As for the spiffy new algos. don't expect to see them before 2004 or 2006 in your favorite browser. ;)

[-h]

They chose the best compression at the time -h. You know when PNG was rattified right?

Nah, PNG files can be 20% smaller just by using context-sensitive huffman coding, which brings about a 3% speed hit and 50 more lines of code. That's the experience I'm having with a lossless codec I'm working on right now, which is basically PNG using a median predictor and quasi-order-2 huffman. Seriously, they could have done *much* better, even back then.

For me it's just one of those nagging annoyances, one of many :)

-h