Spatial/temporal smoothing and MPEG blocks

[SansGrip]

While encoding to MPEG-1 some fairly noisy live-action material captured from VHS I've noticed that too much smoothing results in the appearance of blocks in the final output. Since the Q level of the MPEG file is a pretty constant 1.0 all the way through, I don't think these can be attributed to a lack of bits, but are perhaps a compression side-effect resulting from too little detail.

For example, a pretty strong smoothing with Cnr2(), SmoothHiQ(5, 25, 35, 200, 0) and TemporalSoften(2, 5, 5) followed by an MSharpen(10, 75) to pick out the edges looks very good on my monitor when played from the .avs, but the .mpg has extremely noticible blocks and if anything looks worse than the unsmoothed source when played on a TV.

I've not done enough experimenting yet, but it seems that the temporal smoothing might be the culprit, since when I remove it the majority of the blocks disappear (but the video starts looking noisy again). Using Unfilter(60, 60) instead of MSharpen also reduces the blockiness, since it's adding some noise back in to the picture.

Is there a known property of MPEG that accounts for this phenomenon? Are these macroblocks or IDCT blocks? I'm not sure what the difference is. Is there a particular type of noise (e.g. low/high frequency, or luma/chroma) that is more effective at reducing these blocks in the output without introducing too much perceptible graininess or causing blocks during high motion?

Reading back on this has me wondering if there's not some TMPGEnc setting that I got wrong (perhaps the MPEG quantization matrix would work better than the default one), but I'm hoping one of the many clueful in this forum can point me in the right direction :)

[WarpEnterprises]

do you encode VBR?
if yes maybe the whole bitrate gets too low (TMPG tends to spent too little).
Try a minimum setting of ~500

if no then ??? describe your blocks (the size) or post a sample

[SansGrip]

Originally posted by WarpEnterprises
do you encode VBR?

Nope, 352x240 CBR at ~2500. There should be no blocks at that resolution and bitrate, because the sample clips I'm using do not have much motion.

if no then ??? describe your blocks (the size) or post a sample

I'm capturing right now, but when I'm done I will post an example of what I'm talking about. It's not as pronounced on my monitor, but the blocks are certainly visible.

[-h]

Nope, 352x240 CBR at ~2500. There should be no blocks at that resolution and bitrate, because the sample clips I'm using do not have much motion.

It's probably bad management of the bit bucket then. CBR does put some rather ugly constraints on how a codec is allowed to allocate bits, particularly MPEG-1.

Also I have quite a few clips which create blocking for MPEG-1, MPEG-2 and MPEG-4 at that bitrate/resolution, and they're fairly stationary too. One of the keys to encoding is filtering - you might just have to do more. Or use TMPGEnc's soften-block-noise feature.

-h

[SansGrip]

-h: It's probably bad management of the bit bucket then. CBR does put some rather ugly constraints on how a codec is allowed to allocate bits, particularly MPEG-1.

Hmmm, interesting. What are the constraints? Does this imply that *adding* some noise to those areas might help?

-h: One of the keys to encoding is filtering - you might just have to do more.

Like I said I was doing some quite aggressive smoothing on it, almost to the point of losing edge detail. I'll post some samples of what I have right now and will try some more aggressive smoothing.

-h: Or use TMPGEnc's soften-block-noise feature.

I was wondering if this might help. That's another thing I'll try when I've finished capturing.

[-h]

Hmmm, interesting. What are the constraints? Does this imply that *adding* some noise to those areas might help?

Just going from memory, due to the initial requirements for MPEG-1 CBR (storage on a CD to be read at 1x), each second of the audio/video stream must consume exactly 1.4 Mbits. Thus, regardless of the complexity of that second's worth of content, each frame must be quantized harshly enough to allow it to fit inside its portion of that 1.4 Mbit buffer. There is some leeway as to how much of the buffer each frame can consume (VBV buffer size), so each frame doesn't have to use *exactly* its share and some intelligent distribution can be used, but for a complex scene this is still not much use. Since you can't really force the codec to use more bits on a given frame, all you can do is apply more smoothing to the entire scene or enable soften-block-noise. I realise you're using a higher bitrate, but the same CBR constraints still apply.

Try increasing the VBV size too, it might provide some additional help. Also, increasing the number of P-frames in the GOP may help the encoder out (also try increasing B-frame frequency from 2 to 3 per P-frame, seeing as you have low-motion content). Keep the total frames-per-GOP count below 25 though.

-h

[SansGrip]

-h: Thus, regardless of the complexity of that second's worth of content, each frame must be quantized harshly enough to allow it to fit inside its portion of that 1.4 Mbit buffer.

I see - that makes sense. Though it's strange they allowed higher bitrates in the specification but didn't take that into account with regards to the quantization.

-h: Try increasing the VBV size too, it might provide some additional help.

Increasing from 40 to 200 didn't seem to have any effect.

-h: Also, increasing the number of P-frames in the GOP may help the encoder out (also try increasing B-frame frequency from 2 to 3 per P-frame, seeing as you have low-motion content).

I've found that as far as DCT blocks go, the I-frames are by far the worse offenders. The "spoilage" that occurs between I- and P-frames and I- and B-frames actually reduces the blockiness in static areas. This is even visible during playback: blocks in static areas (blank walls etc.) seem to "pulse" between solid and noisy every second or so.

-h: Keep the total frames-per-GOP count below 25 though.

I read somewhere that the maximum GOP size is 18 for NTSC. Is that not correct?

Interestingly, MPEG-2 I-frames are *much* less blocky. If only my standalone would play SVCD's... :angry:

At http://www.jungleweb.net/~sansgrip/blocks.png you'll find a composite of frame grabs to illustrate what I'm talking about. The left column is the original source (VHS capture via Avisynth), the right column is the MPEG-1 encoding. The top row is without noise reduction, the bottom row with noise reduction.

[-h]

This is even visible during playback: blocks in static areas (blank walls etc.) seem to "pulse" between solid and noisy every second or so.

Yep that's the I-frames in action.

I read somewhere that the maximum GOP size is 18 for NTSC. Is that not correct?

You are correct. I've no idea where I got my figure from now that you mention it..

Interestingly, MPEG-2 I-frames are *much* less blocky. If only my standalone would play SVCD's... :angry:

That's probably more to do with MPEG-2's buffer flexibility than anything inherit in the format itself. Your standalone doesn't support VBR MPEG-1 streams either?

Perhaps you should consider a different intra matrix for your encode.

At http://www.jungleweb.net/~sansgrip/blocks.png you'll find a composite of frame grabs to illustrate what I'm talking about.

Unfortunately my monitor has gotten so dark that I can hardly make out any shapes. At least I can't see any blocks :)

-h

[SansGrip]

-h: Your standalone doesn't support VBR MPEG-1 streams either?

I conducted some brief tests when I first got it and established it could do CBR MPEG-1 up to 2532 + 192. I remember VBR failing, but I've not investigated it thoroughly. Doesn't really matter, though, as those blocks are there in VBR mode too :)

-h: Perhaps you should consider a different intra matrix for your encode.

I've searched for "advanced" information on TMPGEnc and the quantize matrix and didn't find much. Perhaps I should generalize it to other encoders?

-h: Unfortunately my monitor has gotten so dark that I can hardly make out any shapes. At least I can't see any blocks :)

hehehe sheesh

I increased the gamma somewhat to compensate for a TV's extra brightness, but it could probably use a little more - they're clearly visible on a TV set. You'll also want to zoom in, and look at the very left and very right sides of the frame.

[-h]

I can't suggest much more, apart from more filtering for such sections or trying a different encoder in the hope that it's better.

For display on a TV, increasing gamma might be hurting you. Try offsetting the luma by -2 as described in the XviD forum, it seems to have worked for many people to reduce the appearance of blocky dark areas when shown on TVs.

-h

[SansGrip]

-h: I can't suggest much more, apart from more filtering for such sections or trying a different encoder in the hope that it's better.

I already tried CCE and it's just as bad.

One theory I have is that I'm not temporally softening it enough to remove the VHS noise, because anything over about threshold=6 produces too much ghosting in areas of motion. To this end I'm working on (yet another?) motion-sensitive temporal smoother. When/if I get it working I might try to add spatial smoothing to high-motion areas.

-h: For display on a TV, increasing gamma might be hurting you.

What I meant is I increased the gamma of the frame grabs for display on a monitor. I capture with the correct gamma for display on a TV, but looks way too dark on a (properly calibrated) monitor.

-h: Try offsetting the luma by -2 as described in the XviD forum, it seems to have worked for many people to reduce the appearance of blocky dark areas when shown on TVs.

Sounds like it's worth a shot, but I fear it'll just produce slightly darker blocks ;)

Thanks for the help. Much appreciated.

[-h]

One other thing you can try is ffmpeg, I posted a link to a binary in the New A/V Formats forum. Make sure you enable the -hq mode.

Apart from that, you may just be out of luck.

-h

[SansGrip]

@-h

Incidentally, I just created a new thread ("Weird horizontal streaks") including a frame grab of what I think is causing this problem. The streaks not only cause low-quality encodes but also confuse Telecide() into decombing fairly frequently.