View Full Version : Overcropping as Option?
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.
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
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.
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.
Good point, I didn't consider this. Don't we have a similar problem with any resizing then?
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.
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.
shouldn't c. have the most black area?
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.
... 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.
interesting stuff, so it appears you were right.
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.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.