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.ph...376#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.

4th May 2008, 20:30	#1 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	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). Last edited by Sharc; 10th May 2008 at 17:05.

6th May 2008, 13:27	#2 \| Link
jdobbs Moderator Join Date: Oct 2001 Posts: 20,975	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. __________________ Help with development of new apps: Donations. Website: www.jdobbs.net

7th May 2008, 22:53	#6 \| Link
smok3 brontosaurusrex Join Date: Oct 2001 Posts: 2,392	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. __________________ certain other member

8th May 2008, 07:30	#8 \| Link
smok3 brontosaurusrex Join Date: Oct 2001 Posts: 2,392	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. __________________ certain other member

8th May 2008, 20:24	#9 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	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. Last edited by Sharc; 10th May 2008 at 17:04.

6th May 2008, 22:18	#3 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	What about using the autocrop avisynth plugin? http://forum.doom9.org/showthread.ph...376#post588376

7th May 2008, 07:48	#4 \| Link
Susana Registered User Join Date: Apr 2005 Location: Spain Posts: 181	You can use the filter editor Automatic things doesn't always work, not a good idea

7th May 2008, 21:25	#5 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	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.

8th May 2008, 00:06	#7 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	Good point, I didn't consider this. Don't we have a similar problem with any resizing then?

8th May 2008, 20:29	#10 \| Link
smok3 brontosaurusrex Join Date: Oct 2001 Posts: 2,392	shouldn't c. have the most black area? __________________ certain other member

8th May 2008, 20:39	#11 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	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.

8th May 2008, 22:39	#12 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	... 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.

8th May 2008, 23:59	#13 \| Link
smok3 brontosaurusrex Join Date: Oct 2001 Posts: 2,392	interesting stuff, so it appears you were right. __________________ certain other member

9th May 2008, 12:13	#14 \| Link
Sharc Registered User Join Date: May 2006 Posts: 3,997	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. Last edited by Sharc; 10th May 2008 at 14:18.