Spatial/temporal smoothing and MPEG blocks

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

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

-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.

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

-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.

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

@-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.