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

[djidjo]

Hi folks,

While browsing the forum I found this thread http://forum.doom9.org/showthread.php?s=&threadid=34336&highlight=fitcd+AND+macro%2A

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

[-h]

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

[Ookami]

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: http://shh.dvdboard.de/

Cheers,

Mijo.

[Emp3r0r]

actually, i think this feature has to do with optimal cropping to align mpeg-2 macroblocks with mpeg-4 macroblocks because this increases compression. I'm not sure how this works after resizing but I remember it was a hot thread at one time in this forum. I tried searching for that thread but didn't find it. Anyone remember what I'm talking about?

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

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

[Ookami]

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.

[-h]

It works resizing the visible picture to mod16 resolution avoiding distortions (like stretching the image), padding the overscanned area using addborders(parms) and creating the avs file.

You will achieve better compression if you pad the left and right borders with the outer-most pixel of the same line, i.e. if the top-left pixel is white, and the left margin will be padded by 3 pixels, the 3 pixels next to the top-left pixel should be white as well. Same goes for the top/bottom (if there are no letterbox borders).

-h

[mpucoder]

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

[-h]

could you please tell me where is the source for these assumptions?

It is the nature of the DCT - unless the borders you are creating are always multiples of 8, you will be causing the encoder a great deal of discomfort with the sharp edges being introduced.

As far as I know, a mpeg2 macroblock is a 16x16 pel square at fixed positions, completelly independent of their spatial neighboors (the same is not true for temporal neighbors). So, if I have a sequence of black and white tablechess, done with 16x16 black or white squares, the mpeg2 compressibility should be the same of a completelly black (or white) frames sequence.

Well not exactly, the DC component of each block is predicted from its neighbours. Anyway what you say will hold true, so long as the checkerboard pattern begins on a 16x16 offset - if you've added a 5-pixel border to the left of the checkerboard, suddenly the checkerboard squares overlap different macroblock positions, and will require many more bits to accurately reproduce.

Please, have a look at this page (http://www.uni-kassel.de/~eckhardm/Frame2HQ.htm). It seems that it was used to inspire FitCD "macroblock optimization".

That site suggests that you always add borders that are a multiple of 16 pixels, for the reasons outlined above. You could also get away with multiples of 8, but then you won't get to take advantage of macroblock skipping (should save a few more bits). It is only when the borders you add aren't either 8 or 16, that you should add edged regions by repeating the outer-most pixel. This is what MPEG-1, MPEG-2 and MPEG-4 do to "guess" what lies outside the visible area of the frame to reduce the prediction error during motion compensation.

-h

[-h]

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

[shh]

Since this is about my program, I should perhaps say some words about it. :)

> ...resolution is mod 16. Many programs will invent great-sounding names for ordinary features remember.

The intention of this great name was, to make this mod 16 procedure kind of more transparent to the user. :)

> Please, have a look at this page. It seems that it was used to inspire FitCD "macroblock optimization".

Yes and no. AngelSVCD's pages are a result of a long discussion at the Ultimate Board.

> ... if you've added a 5-pixel border to the left of the checkerboard, suddenly the checkerboard squares overlap different macroblock positions.
> Anyway, if the borders you're creating are not 8 or 16 pel, edging should be used instead of pure black

Right, nobody has doubted that.
That is also what this is all about: The resizing/padding-sizes are chosen to enhance block- and macroblock-skipping and so enhance the encoding.
- Optional black overscan-borders are 8, 16, 24pixel.
- Other destination-sizes of the video are _also_ chosen in that way to match block- or macroblock-boundaries.
Example:
Anamorphic NTSC-film with 718x480 pixel of film resized to a SVCD-res.
For that source it would be better to resize to 448x336 and pad to 480x480 (for a TV-watcher). 448 because the surrounding 16pixel are overscan and you shouldn't encode what you don't see. Also a vertical size of 336 is better than the correct 338...
Because of the special destination-sizes one must crop correctly, to retain the correct aspect-ratio of the film. This is actually done by the program.

Regards,
shh

[-h]

That all sounds good to me :)

-h