What is optimal (macro)block-usage in MPEGs ?

Hi folks, While browsing the forum I found this thread where the fitCD program is mentionned for "optimal macroblock usage". Never heard of FitCD before, I watched the homepage and the readme, but "optimal macroblock" isn't clearly explained... It has sth to do with resizing, but what is it exactly ? Thanks ! Djidjo

I have no idea what it's talking about, I've never heard of "optimal (macro)blocks" in any spec, and certainly not as a pre-processing step. It could be something as plain as making sure the final resolution is mod 16. Many programs will invent great-sounding names for ordinary features remember :) -h

If I got it right, it just means you don't waste space on things you don't see (like the part of the picture that will be in the overscan area of your TV set, anyway) + a few other things. Er, when I look at the readme, everything is nicely explained in the Recommandations section. It does much more than just rounding the resolution to mod 16, but hey, if you don't think it is useful, don't use it. IMO, alone the resizing part is worth of the program (and I would donate just because of that). EDIT: Homepage: Cheers, Mijo.

If I got it right, it just means you don't waste space on things you don't see (like the part of the picture that will be in the overscan area of your TV set, anyway) + a few other things. If it's achieving this by resizing the image to the viewable size and padding macroblocks with partial black (i.e. at left and right), the final result will be of poorer quality. However you will get to see more of the sides than before. -h

I'm not qualified to talk about FitCD, I will try to get a statement from shh, if he's registered here maybe he'll even reply. Cheers, Mijo.

MPEG2 uses DCT for compression (just like JPEG), which is very much dependant on the neighboring pixels.

not true. It is completelly dependant on pel values into each NxN square only. So, if you assume that N=8 for mpeg2, a 720x480 frame will be source of (720*480)/(8*8)=5400 luma blocks, each one completelly independent of the other. The DCT coefficients of a given block has nothing to do with those of the neighbour block. I believe he was referring to the fact, that if the 64-pel region you pass to the DCT happens to have a black square in one half and video in the other, the output coefficients are going to be very large (this translates into high-frequency power in the DCT domain) and require more bits to store. Also, this block will be useless for motion estimation along the X-axis, for the same reason. The neighbour block is not used to predict it. Yes, it is. Sure F(0,0) is calculated only from an 8x8 pel region by the fDCT, but that F(0,0) value (before being written to the bitstream) is predicted from the F(0,0) values of neighbouring blocks. It's all in the spec. Anyway, if the borders you're creating are not 8 or 16 pel, edging should be used instead of pure black. It's just the way MPEG works. -h

That all sounds good to me :) -h