PDA

View Full Version : Overcropping as Option?


Sharc
4th May 2008, 20:30
Maybe this has been discussed before: I wonder if overcropping and adding borders compliant with the "mod16" rule would make sense -- as an option in DVD-RB. I have seen many (anamorphic) disks which violate the mod16 rule badly for the active area as well as for the borders, means bits are wasted for the re-encoding of the transition between active area and black border. Although we might argue that overcropping conflicts with the 1:1 backup idea of DVD-RB, the estimated savings in bits is in the order of 5% could contribute to improving the quality of the active area. I would see this as an option in DVD-RB therefore (enabled / disabled).

jdobbs
6th May 2008, 13:27
I can make it an option easy enough... but the person using it would have to view the source and make the determination as to when and when not to use it. There are so many possibilities (2.35:1, 2:1, 1.8:1, 1.78:1, etc.) and they could be encapsulated in either 4:3 or 16:9 streams.

Sharc
6th May 2008, 22:18
What about using the autocrop avisynth plugin?
http://forum.doom9.org/showthread.php?p=588376#post588376

Susana
7th May 2008, 07:48
You can use the filter editor

Automatic things doesn't always work, not a good idea

Sharc
7th May 2008, 21:25
Agree, and even if it would work flawlessly I still would have to add borders such that everything - i.e. borders and picture - becomes mod16 compliant. Means the cropped picture may not be centered anymore on the screen but slightly offset.
I can do everything manually, of course.

smok3
7th May 2008, 22:53
that would mean that old macroblocks are no longer aligned to new ones, from what i read so far, that would be a bad idea.

Sharc
8th May 2008, 00:06
Good point, I didn't consider this. Don't we have a similar problem with any resizing then?

smok3
8th May 2008, 07:30
i would do quality based encoding with HCenc on the three options;

a. your way (moving the visible area) - non-aligned macroblocks
b. do nothing - aligned macroblocks
c. border is adjusted so that it is mod16 with additional cropping into the visible area - aligned macroblocks, some are modified

then compare what happens with bitrate, quality.

p.s. resizing doesn't count here, that would be another story imho.

Sharc
8th May 2008, 20:24
Here we go (small test clip, no filters)
a. 19386 kB
b. 20675 kB
c. 19620 kB
Active picture size was identical for all 3 cases

b. is largest, as expected, due to the black borders (left/right) leaking into the left/right macroblocks of the active area.
Surprisingly, a. is slightly less than c. I guess this may depend largely on the "blockiness" of the original.
Whatsoever, a (or c) indicate a saving of about 6% in this example where the mod16 violation was only left and right. If top and bottom would also have been violating the mod16 rule, the saving could easily become 10% I guess.

smok3
8th May 2008, 20:29
shouldn't c. have the most black area?

Sharc
8th May 2008, 20:39
Sorry, a and c have identical picture areas. b (the original) has the largest active area (no cropping at all).

Still, the bits are better invested in cases a, c (no border effects) than in b.

Sharc
8th May 2008, 22:39
... here another test, where the original was misplaced in the vertical direction by 8 pixels.

a. 52413 kB
b. 56632 kB
c. 53637 kB

Active size a. and c. identical, borders and picture all mod16. b (=uncropped original) slightly bigger and violating mod16.
Conclusion is same as for the previous test.
a. produced smallest file size. Macroblock displacement compared to the original = 4 pixels vertical.

Apart from the file size: Because a. and c. both obey the mod16 rule there are no wasted bits for representing the sharp transition between picture and borders. The saving is most prominent for I pictures, where the transition macroblocks get about 5 .. 10 times more bits allocated than the adjacent picture macroblocks.

smok3
8th May 2008, 23:59
interesting stuff, so it appears you were right.

Sharc
9th May 2008, 12:13
Indeed surprising that the macroblock displacement (a.) did not produce a bigger file size than (c.) Maybe my originals were just free of any residual blocks. Could also be that the result would be different if I would use a sharp matrix for the encode. So far I used the CCE default matrix in my tests.

Added:
I checked quite a few anamorphic DVDs (PAL 720x576). None was compliant with mod16 for the top / bottom black borders.

An easy solution is to incude in the Filter Editor (example):
f:Letterbox(80,80,0,0).
The actual parameters (top,bottom,left,right) need to be determined experimentally, e.g. with the help of AutoCrop.