high quality mpeg-2 encoding

[jagabo]

Yes, I use Interleave very often.

v1 = WhateverSource().Subtitle("v1")
v2 = WhateverSource().Subtitle("v2")
Interleave(v1,v2)

And a differences script:

v1 = WhateverSource()
v2 = WhateverSource()
sub = v1.subtract(v2) 
substrong = sub.levels(112,1,144,0,255) 

StackVertical(StackHorizontal(v1.subtitle("v1"),v2.subtitle("v2")),StackHorizontal(sub.subtitle("Difference"),substrong.subtitle("Difference amplified")))

[creamyhorror]

^^^^ ah yes, that's what I'm talking about

On very similar encodes, you can use difference masks visualize the differences. So 100% perfect lossless qualilty would look black, but differences show up as non black. This is essentially what the objective PSNR testing does, when averaging the results and spitting out a number. But it's sometimes nicer to visualize where the compression losses /artifacts are occurring

I've been meaning to experiment with this, having read about an Avisynth method to overlay-difference clips. Would have been mighty useful when I was comparing clips in the past.

What do you mean? There is no reason why other people can't post encodes using decent settings. I can post proper encodes for the other encoders; I'm quite familiar with most of them. We are just doing this to make some observations and learn things right?

I was just thinking that we'd need a strong proponent of Mainconcept/other codecs, because no one else would really have that much interest in showing how their preferred encoder stacks up against x264. But if you're willing to do the encodes, I guess that settles things.

I'd like to see someone come in, claim MPEG2's superiority, and try to prove it, though.

[poisondeathray]

Yep, thx jagabo for posting the scripts. You're the actually one who taught me that method a few years ago.
I tend to use after effects for the difference amplified overlays now, because it's easier to swap layers quickly

I was just thinking that we'd need a strong proponent of Mainconcept/other codecs, because no one else would really have that much interest in showing how their preferred encoder stacks up against x264. But if you're willing to do the encodes, I guess that settles things.

Actually it's important to remain as impartial and objective as possible, and show each encoder at their best. You don't have to be a "strong proponent" of an encoder, just be familiar with the settings.

I'd like to see someone come in, claim MPEG2's superiority, and try to prove it, though.

Me too

[poisondeathray]

Below is a link for encodes from some of the other encoders @2.5Mbps, 2pass VBR. Because of this type of content, you could use 1 keyframe for this entire sequence (depending on scenecut threshold), but efficiency gains quickly drop off, and "seekablilty" is greatly reduced. There is a crossover point when quality actually suffers as well. So for consistency, I set max keyframe interval at 300 when possible, which I think is a reasonable once per 10 sec interval. I used high quality settings for each, if anyone wants the complete settings or version numbers for any of the encoders, PM me and I can list them or post screenshots

Notes:
-Apple h.264 . Encoded with QTPro on a lossless .mov intermediate. I've already mentioned the color coefficents issue. There are controls for keyframe interval, but no fine controls for things like b-frames or reference frames for example. Most of this has to do with QT player limitations (e.g. things like >1bframes, b=pyramid, I8X8 will cause stuttering or black screen), so right off the bat, Apple h.264 is at a disadvantage

-DivX 7 (h.264) encoder doesn't have any adjustments or fine tuning like GOP size, short of desired filesize (and even that is approximate, I oversized it a bit, because you can't enter an exact bitrate). I used the GUI, so it's representative of what most people would get. As I mentioned in an earlier post, they trade off quality for ease of use and DivX compatibility certification. Right off the bat, it's at a disadvantage, because of the lack of custom settings. You can compare the difference with MCR (which has more control), since they are both based on Mainconcept's SDK.

-MCR is not like the bundled encoders that come with Vegas, Premiere Pro, Sorensen, TPMG, or other MC licenesed products. The bundled encoders are usually "dumbed down" with very few controls. MCR has quite a few settings and control, but short of the MC studio level encoders such as Cinevision. For example, it doesn't have lumimasking or AQ type functionality. (This test clip is a good illustration of what happens to encoders who don't have AQ).

-VC-1. Encoded with EE2. "Best" profile. Fricken slow.

-VP7. Encoded with vdub. Like h.264, VP7 has the potential to blur, especially when using default settings. Encoded with sharpness = 6 (of 7)

http://www.megaupload.com/?d=YEY476C4

Please discuss strengths/weaknesses and any curious observations & comments

[deadrats]

It looks more and more like this comparison isn't going to happen

first of all i'm sure there are others that will be posting their test encodes and second i have returned to try again with the new test clip, this time i will be doing test encodes with hand brake utilizing x264, media coder utilizing the cuda gpu accelerated h264 encoder and of course mpeg streamclip utilizing apple's h264, and this time i will double check every result to make sure i don't screw up these encodes.

well so much for that plan, i just noticed that poison already did a pretty nice comparison test and i'm sure his encodes would be better than what i could do, downloading now, can't wait to see the results.

[creamyhorror]

I tried to compare Apple, DivX and MCR. On random frames I often couldn't decide which was best; the differences didn't seem to be very great. Preliminarily I'd say (for detail retention):

(teddy bear) DivX H.264 > MCR > Apple
(purty girlfriend) MCR > Apple > DivX

but I'll probably revise my opinion when I compare them properly again tomorrow, against the source, with screenshots. It's probably just me being tired.

[jagabo]

My lagarith clip with MPEG 2 encoding, HC and TMPGEnc Plus. ~3000 average, 8000 max (both encoders appear to have hit 6000 max), 23.976 fps (no pulldown). Not as good as h.264 but I was surprised they weren't even worse:

http://www.megaupload.com/?d=BP98CZEK

[poisondeathray]

I thought someone else was going to post x264?

Here is x264, with some comparison frame shots of each of the encoders and original of the FFV1 clip
http://www.megaupload.com/?d=ETUSXRXK

[creamyhorror]

Let's see dem SSIM numbers guys

[poisondeathray]

Let's see dem SSIM numbers guys

I know you're joking, but for other folks that don't know, the SSIM and PSNR (or any "objective" metric) are a mathematic measure that doesn't correlate completely with human perception of quality. It's an objective measure , trying to measure subjective perception. For example, as soon as you use low level of psy trellis, psy rd, you will notice the SSIM and PSNR metrics will fall, and yet if you took a survey, the majority would probably say it looked better. So if you use settings that optimize for SSIM (e.g. for benchmark tests), you may be imparing subjective quality, yet on paper it's supposed to be "better."

Here is a classic example, where an "objective" measure can fail.

PSNR 37.165


PSNR 38.152


Which do you think has better "quality"? It's always better to use a combination of methods to evaluate "quality", but at the end of the day, it's "your eyes" that provide the best measure IMO

EDIT: fixed correct screenshot

[creamyhorror]

Wait, did you label them right? Because the PSNR 38.152 one is clearly much more detailed...

[poisondeathray]

Wait, did you label them right? Because the PSNR 38.152 one is clearly much more detailed...

Thx for correction

Anyone can test this out for themselve: you can do some encodes use the --tune presets for x264 for ssim and psnr (they both use --no psy), and then do some with psy settings. Remember the psy effects are essentially adding noise, making the picture more detailed. This is a deviation from original, which means a lower Signal to Noise ratio, even though it may "look" better.

Excessively high psy settings can definitely make the picture's subjective perception worse, with excessive ringing and artifacts. Also some types of content are more adversely affected than others e.g. low bitrate scenarios and anime (where clean lines show the noise effects more prominently), and the "noise" requires extra bitrate, which can be counter productive in the low bitrate scenario. But proper use can dramatically improve the end user's subjective perceptions - again this depends on the specific scenario and type of content.

[deadrats]

I thought someone else was going to post x264?

Here is x264, with some comparison frame shots of each of the encoders and original of the FFV1 clip
http://www.megaupload.com/?d=ETUSXRXK

how about you also do a test encode with media coder using the cuda h264 encoder, so that we have a direct comparison of a gpu accelerated h264 codec against the other players in the field.

[poisondeathray]

how about you also do a test encode with media coder using the cuda h264 encoder, so that we have a direct comparison of a gpu accelerated h264 codec against the other players in the field.

I don't have an Nvida card, so maybe someone else can do it.

My understanding is that the cuda enabled encoder quality is slightly better than badaboom, which is slightly better than spurs engine cards...which suggests still significantly worse than x264

If you look at these graphs below you can get a general idea of relative quality, since they were done on the same setup, same source. You can see some image quality shots of spurs engine here:
https://forum.videohelp.com/topic371906.html

[poisondeathray]

My lagarith clip with MPEG 2 encoding, HC and TMPGEnc Plus. ~3000 average, 8000 max (both encoders appear to have hit 6000 max), 23.976 fps (no pulldown). Not as good as h.264 but I was surprised they weren't even worse:

http://www.megaupload.com/?d=BP98CZEK

Thx jagabo.

Anyone care to make any comments on HCenc vs. TPMG's encode?

Any guesses at to what approx. bitrate one of the MPEG2 encoder would require on this source to have similar "quality" to the x264 encode?

For completeness, here are encodes of jagabo's lagarith testclip using the other encoders: apple h.264, divx h.264, mcr

http://www.megaupload.com/?d=F3NYZ0JI

[jagabo]

Anyone care to make any comments on HCenc vs. TPMG's encode?

I didn't look too closely but HC looked better in my quick scan. It took several tries with TMPGEnc because it kept missing the target bitrate.

Any guesses at to what approx. bitrate one of the MPEG2 encoder would require on this source to have similar "quality" to the x264 encode?

I did an encode at 20,000 average, 30,000 max and it looked pretty good. Another at 15,000 average and 22,500 max (roughly 1.5 times typical DVD rates because there are 1.5 times as many pixels) still had significant macroblock artifacts.

[poisondeathray]

I did an encode at 20,000 average, 30,000 max and it looked pretty good. Another at 15,000 average and 22,500 max (roughly 1.5 times typical DVD rates because there are 1.5 times as many pixels) still had significant macroblock artifacts.

That was with HCenc? macroblocks @ 15Mbps for real?

I like CCE at high bitrates (relative for DVD resolutions) slightly better than HCEnc for MPEG2, too bad it doesn't do >SD resolution to test out

[jagabo]

I did an encode at 20,000 average, 30,000 max and it looked pretty good. Another at 15,000 average and 22,500 max (roughly 1.5 times typical DVD rates because there are 1.5 times as many pixels) still had significant macroblock artifacts.

That was with HCenc? macroblocks @ 15Mbps for real? :shock:

Yes, at 15K not a lot, but a little.

[creamyhorror]

Ok, finally did some evaluations.

Here is x264, with some comparison frame shots of each of the encoders and original of the FFV1 clip
http://www.megaupload.com/?d=ETUSXRXK

I compared the first frame in the pack (frame 60)...here are the results:

Apple H.264


Mainconcept Reference


VC-1


VP7


DivX H.264


x264


DivX and x264 are clearly ahead of the rest, with DivX slightly in the lead IMO. Both are detailed, but x264 is less true to the source (it has micro-shifting), probably due to psy-RDO. On the other hand, x264 has grain/detail everywhere while DivX has very faint blocking and is slightly more smoothed.

But when I compare one of the later frames (750):

x264


DivX H.264


DivX does a horrible job on this frame compared to x264. I'm thinking it's a difference in frametype and quantization.

In this comparison, from what I can tell, DivX preserved detail well up to a certain threshold, but once past it, everything got smoothed. x264 was more conservative in retaining detail, so it kept detail which DivX considered to be noise and smoothed away.

It's hard to tell exactly which one wins out overall, since frametypes and quantizations don't match. I'd like to know the SSIM figures, if they're available. Did you happen to calculate them, PDR?

[poisondeathray]

No sorry I didn't save the SSIM values.

It's important to look at the entire picture; I want to draw your attention specificially in the shadow details and backround details (I know you're busy looking at the girl , but try to look away for a moment), not so much in the "bear" sequence, but definitely in all the others. Flip between the screenshots, and compare with the original - it should be pretty obvious

This difference is almost all AQ. Almost all encoders (h.264 and otherwise) underallocate to dark scenes and shadow areas, leaving the details obscured. If you lower the AQ value or disable it , the allocation pattern of x264 becomes similar as the other encoders. I'll post some other dramatic examples to illustrate later

[poisondeathray]

This is a short AVCHD 1080i30 camcorder clip, yadif, lanczosresized 720x400, encoded at 1000kbps. You can find the original here for your own testing and learning: http://www.megaupload.com/?d=9B84U1II

It's a good clip to illustrate what x264's AQ does. Now there is no model here to distract you . Pay attention to the shadow detail, and details in the water (and under the water). After examining this clip, go back to the FFV1 clip and re-examine that one. If you still can't see the differences clearly, I'll post cropped image to highlight some of the bigger differences.

Not to sound like a broken record, but again this is a single frame just to illlustrate a point, and you should be looking temporally at the whole clip, different frames, different quality measures, etc. etc....blah blah blah....you get the point. Note I only posted AME , but every encoder that doesn't have AQ like functions has similar results (I tested about 20 different ones)

Original


Adobe Media Encoder CS4 (based on MC)


x264 AQ=0


x264 AQ=0.5


x264 AQ=1.0


x264 AQ=1.5

[creamyhorror]

No sorry I didn't save the SSIM values.

It's important to look at the entire picture; I want to draw your attention specificially in the shadow details and backround details (I know you're busy looking at the girl , but try to look away for a moment), not so much in the "bear" sequence, but definitely in all the others. Flip between the screenshots, and compare with the original - it should be pretty obvious

I barely even looked at the girl, because the big differences were in the details of the rocks and the leaves. I did a lot of instant flipping back and forth.

This difference is almost all AQ. Almost all encoders (h.264 and otherwise) underallocate to dark scenes and shadow areas, leaving the details obscured. If you lower the AQ value or disable it , the allocation pattern of x264 becomes similar as the other encoders. I'll post some other dramatic examples to illustrate later

Can you point out the AQ difference in the 2nd frame I compared? As far as I could tell, DivX was deblocking/smoothing significantly more than x264 was. Is that what you mean by the difference caused by AQ?

[poisondeathray]

I barely even looked at the girl, because the big differences were in the details of the rocks and the leaves. I did a lot of instant flipping back and forth.

I was just joking , I don't blame anyone for looking at the girl . But you're right, the big differences are in the rocks and leaves. Go back to the encodes, not the representative screenshots, you will notice EVERY frame is worse in those areas compared to the x264 encode, so it's not simply a matter of frametype decision or quantization. Use the avsp or interleave methods, and this will by crystal clear. If I re-encode the video with x264 with AQ off, I am willing to bet it would look as blurry as the other videos

Can you point out the AQ difference in the 2nd frame I compared? As far as I could tell, DivX was deblocking/smoothing significantly more than x264 was. Is that what you mean by the difference caused by AQ?

This was exactly my point, the intra frame allocation to dark/shadow areas of most encoders is low, causing the smoothing and lack of detail. You can see the same type of thing in the pond/tree camcorder example I posted above with varying AQ strength. [i The point is that the other consumer level encoders don't have AQ or similar lumimasking [/i] , which is one of x264's big strengths. Note that xvid has a VAQ patched build, and HCenc has AQ as well (both ported from x264) but they do not work as well as x264's version.

On the 1st sequence, the images are closer in quality between the h.264 encoders. I agree the Divx h.264 and x264 probably look the best, but the nose texture on the DivX encode is missing and that separates it for me

On the 2nd sequence, look at the detail differences in the shadows behind the water, and near the pioneer logo. Some of the encoders completely drop and smooth the detail. Again this is largely the effect of AQ

On the 3rd sequence, as you already pointed out, biggest differences are in the rock & leaves shadow detail. AQ again.

On the last sequence, where the girl has her hand on the palm tree. Look at the palm tree, compare the detail with the x264 encode vs. the others. Look at the leaves in the background, on some of the other encodes, entire leaves and textures are missing. Compare the sharpness of the details. This is largely due to AQ.

Play with different AQ settings when you do your x264 encodes, and you will learn how it affects different types of content. The general principle is illustrated in both the camcorder pond/tree example, and this FFV1 example.

[creamyhorror]

On the 1st sequence, the images are closer in quality between the h.264 encoders. I agree the Divx h.264 and x264 probably look the best, but the nose texture on the DivX encode is missing and that separates it for me

In my comparison, DivX preserves more of the original detail over most of the frame. x264 seems slightly blurrier, where it isn't microshifted/distorted. But it's a very small effect. I'm just assuming this is the price to pay for small bitrate savings which can be better used elsewhere.

The microshifting of fine detail was completely absent in DivX's frame. Is it a result of x264's psy-RDO, or something else? Do you need me to clarify what shifting I'm talking about? (It resembles the shifting you get when you use HQDn3D...)

If I recall what I read about AQ correctly, it helped improve static image quality/detail (presumably at the expense of motion). Sound right to you?

[poisondeathray]

On the 1st sequence, the images are closer in quality between the h.264 encoders. I agree the Divx h.264 and x264 probably look the best, but the nose texture on the DivX encode is missing and that separates it for me

In my comparison, DivX preserves more of the original detail over most of the frame. x264 seems slightly blurrier, where it isn't microshifted/distorted. But it's a very small effect. I'm just assuming this is the price to pay for small bitrate savings which can be better used elsewhere.

The microshifting of fine detail was completely absent in DivX's frame. Is it a result of x264's psy-RDO, or something else? Do you need me to clarify what shifting I'm talking about? (It resembles the shifting you get when you use HQDn3D...)

If I recall what I read about AQ correctly, it helped improve static image quality/detail (presumably at the expense of motion). Sound right to you?

Yes i agree with what you call "microshifting." I think this is largely from psy-rd. I think --psy-rd 0.5:0 was used. It works to highlight edges and detail, almost like a sharpener. If you disable psy on content with grain for example, you can see much less grain and detail preserved, but if you go overboard, you get ringing and rough artifacts especially at edges. (for example, on the lagarith jagabo sample, I used --psy-rd 1:0, because the encode at --psy-rd 0.5:0 dropped too much of the detail and grain for my tastes). I tend to go with lower values in general, but it varies on situation. I wouldn't be surprised if this specific sequence has a lower psnr value, as psy settings do lower ssim/psnr

The new AQ in the recent builds have 3 different modes (as opposed to strength), 1,2,3. They all can redistribute between frames (interframe). Defintely work temporally, not just intraframe. Have a look at the park/pond video below, I included the AQ1.5 and the AME encode to compare. Compare the motion and smoothness temporally.

http://www.megaupload.com/?d=7FKI4R8A

The trade off or "side effects" of using AQ with (normal strengths) is quite minimal on most types of content . It can hurt smooth content like anime, and things like graphic titles, where edges get more ratty, and the "side effects" are more pronounced at low bitrate levels, much like psy side effects. But since it redistributes bits, you have to look at the whole frame , and other frames temporally as well (because the reallocated bits have come from somewhere) - ie. is the AQ strength so high that it degrades other frames or parts of the same frame? As usual , there is no 1 setting for every scenario and YMMV.

[creamyhorror]

Good stuff to mull over. I'll do the comparison of your pond encodes later today/tomorrow, because I'm on my small laptop at the moment.

I can sort of see that psy-rd may be responsible for both the "microshifting" and the grain, because the x264 encode certainly had more fine grain-detail than the slightly smoother DivX one. I can't help but think that a lower psy-rd value may have been better, since the fine grain would be unnoticeable in real playback.


All this aside, I think it can be safely taken that we've investigated MPEG2, XviD, H.264 and other codecs enough to come to some conclusions. x264 beats the other H.264 encoders in this test, and jagabo has found MPEG2 to be less efficient and prone to macroblocking.

I hope we can agree that it's pretty much settled that MPEG2 (and XviD) does not beat x264. If anyone claims otherwise again, we should direct them to this thread and ask them to prove it.

Hurray!

[deadrats]

I hope we can agree that it's pretty much settled that MPEG2 (and XviD) does not beat x264. If anyone claims otherwise again, we should direct them to this thread and ask them to prove it.

i would say that what was proven is that given enough bit rate all the mpeg-4 encoders asp or avc give results that are reasonably close to one another; it's only when you drop the bit rate to ridiculously low levels that you start to see any differences.

as for mpeg-2, i have to disagree, all we proved is that the encoders we used are sub-standard, i would like to see a comprehensive mpeg-2 comparison with main concept. ffmpeg, mencoder, nero's recode (<--a really good mpeg-2 encoder in my opinion), cce basic (perhaps the cream of the crop, as far as mpeg-2 is concerned) and procoder.

all i know is that i have seen some italian adult dvd's that are clearer and crisper than some commercial blu-ray's, and even if we assume that the adult movie was shot with a hollywood caliber camera, with the most perfectly focused setting possible, and absolutely perfect lighting, i still don't see how a dvd spec mpeg-2 can be clearer than a commercial blu-ray.

[poisondeathray]

i would say that what was proven is that given enough bit rate all the mpeg-4 encoders asp or avc give results that are reasonably close to one another; it's only when you drop the bit rate to ridiculously low levels that you start to see any differences.

I would say nothing is "proven" on this small sample size. These are just a few observations. I've done 100's of these tests for myself, and my observations are large differences exist between AVC encoders with high quality sources, such as high quality blu-ray transfers. The tests here were done on medium quality sources, so the difference might not have been as clear. Take the island studio trailer that I posted the links to earlier. It's a heavy grain lagarith encode from DPX. Huge differences in terms of detail and grain retention, using blu-ray bitrates for the encode. Mainconcept based AVC encoders need about 1.4 - 1.6x the bitrate to keep up with x264. Xvid needs 1.7-1.8x. MPEG2 needs >2x ! So if you're making a blu-ray backup for yourself, the difference would be using BD25 vs. BD50 media. $5-7 vs. $25-30. I would call that significant

You will find if you do examine enough tests, mainconcept based encoders are the ones that give AVC the bad name. They oversmooth and lack detail in shadow/dark areas. Even these couple of mini tests showed that trend. One of the big selling points of using AVC is compression. If you need 1.3-1.4x the size just for equivalent quality, why bother? Everything looks good given enough bitrate LOL. The point is x264 reaches any certain "quality" level at a much lower bitrate than other AVC encoders, MPEG2 or MPEG4-ASP, and this has been shown many many times in other threads and other forums. What we should be doing is varying the bitrate, and seeing at what bitrate the "quality" is matched or a certain quality level is obtained

I'm still looking for that source/scenario where this trend doesn't happen... If you're "not impressed" by x264 encoders, it's usually user error as the root cause, as was the case here.

all i know is that i have seen some italian adult dvd's that are clearer and crisper than some commercial blu-ray's, and even if we assume that the adult movie was shot with a hollywood caliber camera, with the most perfectly focused setting possible, and absolutely perfect lighting, i still don't see how a dvd spec mpeg-2 can be clearer than a commercial blu-ray.

I've seen some bad blu-ray transfers too. Some are worse than low quality DVD! Some are just upscaled DVD. Many are lowpass filtered. It all depends on the transfer. Now if you upscaled that adult DVD, do you think it would look even 1/2 as good as an average quality blu-ray? I think not. The loss of resolution is what hurts DVD the most IMO. For example, if that same production company that did your italian DVD, also made a blu-ray from the same master, it would look much much better.

[creamyhorror]

i would say that what was proven is that given enough bit rate all the mpeg-4 encoders asp or avc give results that are reasonably close to one another; it's only when you drop the bit rate to ridiculously low levels that you start to see any differences.

2500-3000kbps for 720p is medium, not low.

as for mpeg-2, i have to disagree, all we proved is that the encoders we used are sub-standard

I thought HCEnc was considered to be very good?

nero's recode (<--a really good mpeg-2 encoder in my opinion), cce basic (perhaps the cream of the crop, as far as mpeg-2 is concerned) and procoder.

Well, someone with those tools will need to volunteer to do the testing. Do you have them?

all i know is that i have seen some italian adult dvd's that are clearer and crisper than some commercial blu-ray's, and even if we assume that the adult movie was shot with a hollywood caliber camera, with the most perfectly focused setting possible, and absolutely perfect lighting, i still don't see how a dvd spec mpeg-2 can be clearer than a commercial blu-ray.

If you've really encountered that, you should take some snapshots or even sample clips for us (remember to choose safe-ish scenes!). I'd certainly be interested

Excuse our skepticism, because it really doesn't seem very likely that MPEG2 beats x264. At very high bitrates, they look similar, but that's about it.

[aedipuss]

if you guys want more mpeg-2 encode snaps let me know. i didn't know exactly what frame number was used but here is a cce sp2 5 pass 6mbps ave. encode frame.