There is more about cropping than meets the eye...

[duartix]

About one hour ago I was set out on this very simple mission: to find out what was the real overhead of the black bars framing the picture in terms of bitrate abuse.
Well a simple mission it turned out NOT to be! Taking some inconsistent test aside (probably because I forgot to take out the audio in some of my first tests)

I did these tests with Bruce Lee's Enter the Dragon. My source was a AVI file, a 592x352 pixels rip. The frame was 44 pixels on top, 44 on the bottom. So I performed 3 groups of tests on a 10 second piece.

Crop tests:
Test 1: Don't crop.
Test 2: Crop 32 on top and bottom. Final resolution 32 multiple.
Leaves 12 pixels bar on top, and 12 on the bottom.
Test 3: Crop 40 on top and bottom. Final resolution 16 multiple.
Leaves 4 pixels bar on top, and 4 on the bottom.

Codec tests:
Test A: DivX 3.11 - Low motion - Bitrate 6000
Test B: DivX 4.12 - 1 pass - Maximum & minimum quantizer 2. 6000kbps.
Test C: XVID - 1 pass - Quantizer 2.

My findings were not what I expected but really cleared out one point which wasn't and hasn't been issued at least for THIS reason: MOD 32 Resolutions compress better!!!
I haven't seen this adressed nor in guides nor in other posts.

Here is a small matrix of my tests, filesizes in KB:
----------1----2----3
Test A) 2880 2876 3904
Test B) 3650 3624 4490
Test C) 3272 3110 3554

Losses of bitrate in terms of percentage:

Original Cropped32 Cropped16
A) x.........0%...........+36%
B) x.........-1%..........+23%
C) x.........-5%..........+9%

A quick test with a cropped to 8 pixels multiple showed even bigger abuse of bitrate.

Damm board, duplicated my post when I was submiting an edit. Well, I've tried this with a bigger portion of video and the diference of cropping in XVID dropped from 5% to 2%. So this just tells me how very little bitrate can be gained by cropping to a MOD 32 resolution (still by all means DO IT) but how much a lot of bitrate can be lost by baddly doing it. This is an alert based on a very quick test. I would appreciate other people's results and comments posted.

[b0b0b0b]

How much of the black bars in both cases remained in the picture after cropping?

Did both crops leave you with no black bars at all? If so, this is a great finding.

[b0b0b0b]

Is this in xvid only?

[duartix]

I've just reedited the post, I hope I've made it clearer.
I performed 9 tests. For each of the 3 codecs (A,B,C) I've tested each of the 3 methods (1,2,3).
So I guess that there must be something with the encoding of the macroblocks that makes it more dificult if their dimension is not 32.

[b0b0b0b]

Your results table doesn't make any sense:


----A----B----C
1 2880 2876 3904
2 3650 3624 4490
3 3272 3110 3554


The table says that the original (1) compresses the best and mod 32 (2) compresses the worst.

edit: oh I get it, you mislabeled the axes.


What do the results look like if you crop down to mod 32 & mod 16 with no black bars left at all?

[duartix]

I'm really sorry, I've had the axes of the table mislabeled, thanks b0b0b0b (original post now corrected)

What do the results look like if you crop down to mod 32 & mod 16 with no black bars left at all?
Well after 32 on top/bottom I did a small MOD 32 test at 48 crop on top/bottom. You would get a smaller filesize than at 32 on top/bottom as it should be expected.
It turns out that the first MOD 16 to take out completely the black bars is this very 48 on top/bottom which is also a MOD 32.

Numbers are:
48 top/bottom crop
Test A) 2452KB -15% bitrate than no crop. (divx 3.11)
Test B) 3154KB -14% bitrate than no crop. (divx 4.12)
Test C) 2858KB -13% bitrate than no crop. (XVID)

Now, are you ready for this?
The first MOD 8 crop that takes out the bars:
44 top/bottom crop
Test A) 4510KB +57% bitrate than no crop. (divx 3.11)
Test B) 4940KB +35% bitrate than no crop. (divx 4.12)
Test C) 4316KB +32% bitrate than no crop. (XVID)

It gets bloody well worse!!!

Note: Due to the nature of these results and their serious effects, I'm really not inclined to perform any other tests until someone else backs me up with at least some quick tests of their own.

[kermit70]

Very enlightening, duartix. That proofs what I been suspecting all along. Not cropping and keeping the black bars has only a marginal effect on the bitrate. When I began making Divx rips, I used to crop & resize extensively trying to find the best resolution. Now I just leave it alone and go for 2 or 3 CD's. Saves a lot of time and effort and they even encode faster (no resizing).

kermit70

[sneeky]

Test Conclusion:

When using DivX 3.11 codec:

-Test data supports cropping of black bars to reduce file
size for similar quality encodings.

-Test data supports cropping of black bars to reduce the
duration of the encoding process.

-Test data supports using multiples of 32 or 16. (Note 720
is a multiple of 16, and 704 is a multiple of 32.)



Test Procedure:

-Select chapter 5 of Matrix DVD for encoding sample.
-Create DVD2AVI (720x480) project without cropping and feed
to NanDub RC2.
-Use Null Transform filter to perform various crops.
-Encode using DivX 3.11 codec.
-Set bitrate to 6000kbs.
-Use "one pass, constant DRF" (tests performed separately
on DRF2 and DRF3).
-Record each encoding session file size and duration.

-Note: Active Movie area is 704x356. Black bars represent
the remaining area. In the case of 720xXXX, there are small
bars (8 pixels wide) on the side of the frame.
-Only cropping allowed. No resizing so as to present similar
Active Movie areas.

Data:

DRF2

-720x480 - 69.3MB - 669 secs. has black bars
-704x480 - 67.8MB - 662 secs. has black bars
-720x352 - 57.4MB - 579 secs. small black bars
-704x352 - 56.3MB - 575 secs. no black bars


DRF3

-720x480 - 34.9MB - 662 secs. has black bars
-704x480 - 34.3MB - 661 secs. has black bars
-720x352 - 29.9MB - 537 secs. small black bars
-704x352 - 29.4MB - 535 secs. no black bars

Addendum: Additional Data

DRF2

-720x472 58.8MB 661 secs. **
-704x472 57.6MB 658 secs. **
-720x464 69.3MB 659 secs.
-704x464 67.8MB 652 secs.

-720x360 58.3MB 598 secs.
-712x360 55.3MB 591 secs. **
-704x360 57.1MB 593 secs.

** unexpected file size reduction, file contains
same number of frames & keyframes at same DRF ...


Addendum2: More Data

DRF2

-712x352 53.4MB 578 secs. ***
-712x472 55.9MB 656 secs. **
DRF3

-712x352 28.5MB 540 secs. ***
-712x472 30.2MB 612 secs. **

*** Smallest file size as tested. Interesting since the horizontal
resolution is a multiple of 8 and the frame size increased slightly
when compared to 704x352. I did not notice a significant difference
when comparing slight changes in vertical resolution from 352 to 360.
Changing the frame size 360/352=1.02 which is pretty much in line
with the file size changes. But with a then 712/704=1.01, the file
size drops 53.4/56.3=0.95. This is significantly different.

[duartix]

I believe there are two issues here, which I have to separately adress: Vertical Resolution (VR) and Horizontal Resolution (HR).

@kermit:
I think you should still crop to the MOD 32 (VR) resolution that takes out the maximum of the black bars. In sneeky's test it resulted in a 17% gain in bitrate. Not only that but you will also have a faster encoding AND decoding.

@sneeky: (this is the second time I mispell your name for speedy :))
From your test what we see is something perfectly normal and that should be expected:
(HR)704 is cheaper than HR 720. HR 704 (a MOD 32 Resolution) is 2% cheaper than HR 720 (a MOD 16 Resolution). What I expected was a much heavier expense at HR 720, since it is a MOD 16. But that didn't happened. Why, I ask?

Now this reminded me of JPEG Wizard. It's a program for losslessly cropping JPEG images. It takes out surrounding frames without recompressing JPEG macroblocks. I have just been testing some suspicion and found this out: Take an image lets say it's size was was 200x200. When you crop to 160 (VR) the filesize is X, when you crop to 159 VR the filesize is still X, and only when you crop to VR 160-16 will you get a filesize drop. That indicated me that the blocks had a 16 pixel HEIGHT and were saved integrally and only when you could supress a whole line of blocks would the filesize drop. Now when I tested cropping to 160 HR I imediately got a filesize drop as soon as 160-8 HR which perhaps indicated a 8 pixel JPEG macroblock WIDTH. So my conclusion was that the JPEG blocks were 8x16.

Can't the MPEG macroblocks be 16x32? Anyway why does the filesize increases? I can't even begin to guess...

Now, I know I'm stepping on loose ground so please I would apreciate some more people posting tests.

@speedy:
Both your VR, 480 and 352 were MOD 32. Please, I need you to perform a test with a MOD 16 VR like:

-720x464 - has black bars OR
-704x464 - has black bars

[ppera2]

Originally posted by kermit70
...When I began making Divx rips, I used to crop & resize extensively trying to find the best resolution. Now I just leave it alone and go for 2 or 3 CD's. Saves a lot of time and effort and they even encode faster (no resizing).

kermit70

Crop and resize is 2 different thing. I usually resize only one dimension downside to get correct aspect ratio. If you not resize you need player capable to change AR (except very few DVD's).

And when resize only one dimension (usually vertical) with bilinear it is really fast, and encoding is faster due to smaller size, so at end it is only some 10 % slower. I can encode with 33 fps 704x304 with Athlon at 1386 MHz.
Finally, there is lot of PAL DVD with full 720x576, it is little too big I think.

[kermit70]

Originally posted by ppera2


Crop and resize is 2 different thing. I usually resize only one dimension downside to get correct aspect ratio. If you not resize you need player capable to change AR (except very few DVD's).

Yes, I use bsplayer & radlight. These players give you the most freedom regarding aspect rations (16x9 works fine with anamorphic titles).

Finally, there is lot of PAL DVD with full 720x576, it is little too big I think.

My newer PAL rips are all full 720x576 and they play just fine on my 1,2GHz Athlon (30-50% cpu utilization).


kermit70

[LotionBoy]

Alrightie, now this has gotten my interest. Been much too busy to do any serious Xvid testing (or any encoding for that matter), but this cropping thing interests me. I've just queued up 5 tests using Xvid and Crouching Tiger. Here they are (results will be up tonight. the encodes will be done in about an hour, but i'll be at work/class till later).

CTHD
56 top
58 bottom

640x352 (mod 32)
no cropping

640x288 (mod32)
Top Crop = 44
Bottom = 43

Crop-All on. (no black bars)

640x264 (mod32 * mod8)
top = 59
bottom = 61

640x272 (mod32 * mod16)
top = 56
bottom = 58
sides = 5

640x256 (mod32)
top = 64
bottom = 67

And we'll see what the results are. If anyone has some tests they would like me to do, just let me know. It's only about 14 minutes to encode this VOB (mmm, dual Athlons) so I can run a whole batch over night.

LotionBoy

[sneeky]

More data has been posted with regards to previous post.
Several odd data samples are recorded. The Odd Samples are
definitely reproducible. I have saved all the VCFs for each
data set if there is interest.

It is definitely odd that the file size reduction shows up
at XXX x 472, and not at the other settings. Also note that
the Odd Size reduction also shows up at 712 x 360 but is not
as remarkable.

[LotionBoy]

And the results are in

CTHD
56 top
58 bottom

640x352 (mod 32)
no cropping
268,527,616 bytes

640x288 (mod32)
Top Crop = 44
Bottom = 43
267,243,520 bytes



Crop-All on. (no black bars)

640x264 (mod32 * mod8)
top = 59
bottom = 61
265,031,680 bytes

640x272 (mod32 * mod16)
top = 56
bottom = 58
sides = 5
265,426,944 bytes


640x256 (mod32)
top = 64
bottom = 67
249,792,512 bytes

Bascially, what we are getting here is file-size differences (i.e., the smaller the resolution, the smaller the file). But a couple of things stand out.

1. No cropping vs. cropping out most of the black bars does pretty much nothing. About a meg difference, which is probably due to the file-size.

2. Cropping the height on mod8 or mod16 does not seem to do much.

3. Correctly cropping using mod32 and eliminating all blackbars seems to drastically cut file size. Either this is the case, or 256 is some sort of limit which makes thing much easier to compress. I'll do another test with greater horizontal res, which will pull up the vert. as well.

But things to keep in mind. From this test, it appears that cropping off only part of the black bars is not effective. It also appears that setting the height to anything but mod32 causes larger files. Will be back with more later. tell me if there is anything you want me to check.

LotionBoy

[LotionBoy]

Alrightie, the second test is done, and here are results for ya.

Round 2:

Uncropped

704x384 (mod32)
(cropped to fix Aspect Ratio)
top = 2
bottom = 2
314,355,712 bytes

720x400 (mod16)
(cropped to fix Aspect Ratio)
left = 3
right = 4
328,957,952 bytes

Crop-All on (no black bars)

720x288 (mod16 * mod32)
top = 64
bottom = 67
319,977,472 bytes

720x304 (mod16 * mod16)
top = 56
bottom = 58
sides = 3
322,535,424 bytes

704x288 (mod32 * mod32 (mod16 too))
top = 60
bottom = 63
298,463,232 bytes


704x296 (mod32 * mod8)
top = 56
bottom = 58
316,911,616 bytes
sides = 1

Well, this test basically confirms the last set of findings and then some. look at the Uncropped mod32 size. It is smaller than all the non-mod32 file sizes, even those some of them are smaller resolution, and all but i 1 have the black bars removed. Conversely, the mod16 uncropped file shows the shitty overhead that leaving the black bars in can give. And the cropped mod32 file is tiny when compared to the others: 15megs smaller when compared to the next smallest. This is pretty damn impressive. And remember, this is only one VOB. Across an entire movie, the effect would be even greater. Of course, real movies are not encoded at quants of 2, but a prior test seems to show that this holds true for other quant levels as well. So basically, encoding at Mod32 results in lower bitrates, which results in better all around quality in the movie. This is really cool. Great catch duartix to find this.

LotionBoy (who is now going to encode everything mod32 ;-)

[MaTTeR]

Kudo's to you guys! Now I must investigate this myself:D

Indeed duartix, great find.

[Teegedeck]

Congratulations! This qualifies as the most useful thread for a long time!

[diji1]

ditto - thanks all u contributors! :D

[ChristianHJW]

Hmmmm .... very interesting indeed ! Anybody from the XviD dev team to explain this ? Whats so special about the 32 pixel width and height, taking into account that MPEG4 will use 8x8 pixel macroblocks ?

Are we sure that the quantizer really remains the same in all cases ? Somebody to do a test at quant = 15 or 20 and to report if picture quality is identical on all versions .... maybe the quants get f...ed somehow if res is multiples of 32 :confused: ??

Another thing to adress here is to investigate if the sharp border ( high contrast ) between picture and blackbars may cause any problems if they are not cut away completely ? Maybe we get strange effects if there are black bars left being some 8 pixel in height, maybe they interfere with more than one macroblock ( height wise ) ?

Next thing i'd like to know is what happens if you cut away the black bars from the original pic ( as precisely as possible ) and resize to a picture being multiples of 32 pixel in width and height, even if aspect ratio is screwed this way ? We could compare to another encoding with same width ( 32 ) but height being 8 or 16 pixels smaller. The number of total pixels is of course higher in 1st case but not much and its interesting to learn about filesizes.

Dont forget, we could easily implement an 'aspect ratio correction flag' in MCF, so every capable player would read this flag and correct the picture on playback, without anybody even noticing it .... but file sizes being much smaller !

( Please dont ask me to test this myself ..... the deal is, i work hard to help the MCF dev team to make it become reality and you make the testing :D ..)

[sneeky]

I posted an Addendum2 to the previous test samples. All tests
were done using DivX 3.11 . To summarize, the frame size
of 712x352 (MOD8) wins the smallest file size prize.

LotionBoy's post indicates a MOD32 superiority in Xvid as I
interpret it. It would be interesting to test my video sample
using Xvid as well and see if anything changes. Ahh, more testing.

It appears there is definitely a pattern sensitivity in using
these 2 codecs. If it varies from DVD to DVD, it may not be all
that useful. Again, I wonder if using a resize or other filter
alters or destroys the pattern sensitivity (just more testing).

I did briefly test to see if changing iDCT algorithms in DVD2AVI
made any difference, and it did not.

[LotionBoy]

I'll grab a couple more DVDs off my shelf and see what is going on here. Maybe I'll even run some Divx3 tests :-) Got a shitload of work to do tonight (I am Maya's bitch [it's a 3D reference]). So I'll probably queue up some encodes tomorrow. Hope I get Divx3 speeds like my Xvid ones (50fps. dear lord). We will track this down. :-)

LotionBoy

[diji1]

Maybe I'll even run some Divx3 tests :-)

Please do - this is all very interesting, thanks Lotion and everyone else! :D

Hope I get Divx3 speeds like my Xvid ones (50fps. dear lord). We will track this down. :-)

Those DVD's dont stand a chance! Beat 'em down baby! :p

(I am Maya's bitch [it's a 3D reference])

eh ? lol, never mind < diji shrugs and gets back to pasting germans in medal of honour ;) >

[sneeky]

Thanks Duartix for such an interesting phenomenon ...

No conclusions, just a bunch of data ...
But I promise something really interesting in the end ...

I retested Chapter 5 of the Matrix using the Xvid Codec and
will continue using this codec for follow-up testing as it has
dynamic support and interest. I dropped logging encoding times
unless someone is really interested in that data.

Test Procedure:

-Select chapter 5 of Matrix DVD for encoding sample.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.


Data:

Quantizer 2 - All crops symmetrical

-720x480 70.9MB
-720x472 60.3MB
-720x464 70.7MB

-704x480 69.4MB
-704x472 59.1MB
-704x464 69.2MB

Interestingly, behaves much like Divx 3.11 using the same video sample.


More Data:

Quantizer 2

-symmetrical crops............asymmetrical crops - 63 top, 65 bottom

-720x352 68.2MB................-720x352a 58.3MB
-712x352 58.1MB................-712x352a 55.3MB
-704x352 66.7MB................-704x352a 58.3MB

Interestingly, the asymmetrical crops behave just like Divx 3.11
because the Divx 3.11 samples were done just like this at XXXx352.
But note the odd behavior at symmetrical crops 64 top, 64 bottom.

Again, the 712 resolution is the smallest file size.

Again, this is a video sample of one.

Based on the above data, I speculate that moving the crop grid
incrementally should expose a pattern. Since the Mpeg2 & the Divx
formats use matrix patterns, I speculate further that there is some
preferrential alignment pattern to minimize file size.

As to differences in quality of the the different files sizes, I am
no expert, but the smaller file sizes are at least as good. But
anything looks good at Quantizer 2. The smaller file sizes might
actually appear better with respect to the fact the the when viewing,
e.g. Neo's brown suit jacket, the colors in small areas don't appear
to wiggle as much??? Am I seeing things?

These tests were done with Warner's region 1 DVD and I would hope
others could reproduce them.

Any other ideas? I will test moving the crop window around next,
pixel by pixel.

[soujir0u]

Hmm...sneeky's test seems to show that mod8 gives the smallest file size.

BTW, anyone tried testing on DivX4 yet? Or will all the 3 codecs (3.11a, XviD and 4.12) be the same?

[sneeky]

Finally some data that makes sense.

I do not believe that this is a frame size issue, but more
a frame position issue. It would be a mistake to think of it
as simply MOD8 vs. MOD16 vs. MOD32 frame size issue.

I set up a series of encodings to map the large file/small file
occurence in the vertical position mode. I used the same chapter 5
of the Matrix and encoded using Xvid.

I picked a frame size of 720x384 so that there would always be
black bars on the top and bottom of the frame throughout the
series of tests. This means that the active movie portion is
always the same size. It's just the size of the top and bottom bars
vary, but even then, the total number of pixels allocated to the
black bars doesn't change throughout the series of tests.
This is done by cropping the top and bottom of a 480 vertical
resolution accordingly.

Test Procedure:

-Select chapter 5 of Matrix DVD for encoding sample.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.


Data:

Quantizer 2; tXX is top crop; bXX is bottom crop; original frame 720x480;

-720x384 t48 b48 70.7MB **
-720x384 t47 b49 61.8MB
-720x384 t46 b50 61.0MB
-720x384 t45 b51 59.8MB
-720x384 t44 b52 60.0MB
-720x384 t43 b53 60.0MB
-720x384 t42 b54 61.2MB
-720x384 t41 b55 61.9MB
-720x384 t40 b56 70.5MB **
-720x384 t39 b57 61.9MB
-720x384 t38 b58 61.2MB


** Note the large file size repeats itself as the Xvid 8x8 matrix realigns in the offending position every 8 pixels.

I expect that if the frame window moves the other direction, this
phenomenon will repeat as well. I expect this phenomenon to occur
with respect to horizontal position as well. I will test that axis
later.

@LotionBoy ... can I borrow your really fast encoding setup? LOL.
If you get a chance, can you corroborate this phenomenon. I hope my
decription of the test is adequate. It would be nice to get some
sample sizes using more than 5 minutes of a movie. If this concept
holds, the samples can probably reduced to very small clips to
verify other aspects.

[LotionBoy]

rocking out with the encodes tonight, Should have results up by, oh, say around noon EST tomorrow. Maybe early. depends if my morning class or the end of the encoding comes first. stupid nights with out sleep. stupid maya. stupid compsci. grrr. . . .hehe


LotionBoy

[LotionBoy]

and my tests are done, before I have to leave for class. good computer, good computer. :-) And the results are what sneaky would expect. I understand that this is not just a mod32 vs mod16 debate, but one of the things that I found, which I think it very true, is that if you crop off all the black bars and then resize to a mod32 hor. and vert., you will get a much smaller size. Of course, you loose a couple pixels of the movie, but I'll take that if it gives me better quality in a smaller size.

so without further ado, here it is

Round 3

All are unresized. Cropping being down to sneeky's specs/
Res = 720x416

720x416 t32 b32 : 432,812,032 bytes
720x416 t31 b33 : 411,508,736 bytes
720x416 t30 b34 : 412,196,864 bytes
720x416 t29 b35 : 408,639,488 bytes
720x416 t28 b36 : 412,862,464 bytes
720x416 t27 b37 : 409,436,160 bytes
720x416 t26 b38 : 414,685,184 bytes
720x416 t25 b39 : 413,167,616 bytes
720x416 t24 b40 : 432,678,912 bytes

[ppera2]

Funny, but in last couple months I made most of my rips so. Crop to 704 hor, vertical by need and then resize to 704x mu32.

[duartix]

@soujir0u:

From my initial tests, it looks like this sort of behavior is common to all codecs (XVid, DivX 4.12, divx 3.11).

@sneeky:
Way to go! I never would have guessed it could be a frame alignment issue. But still your values fall within a 15% diference. I'm a bit puzzled on how my MOD 8 test at 44 top/bottom crop got well over 30% in all codecs. I wouldn't rule out the MOD issue just yet.

Still, I'm a bit :( I can't help testing since neither do I have a DVD-Rom drive nor a fast enough machine for these purposes (just a PIII@500Mhz). All my experience is just based on encoding Low Rez music videos and second generation rips.
But, I'm also sure that if there is an answer, this community will definitively be the one to get it. :sly: :sly: :sly:

[sneeky]

@LotionBoy:

Thanks for the confirmation. Looks like we are headed in the
right direction. I agree that there are other issues that can be
optimized but they are all masked by this position issue.

BTW, what DVD title did you use? .. partial movie?

@Duartix:

Right now we are looking at optmizing only vertical position
and achieving about 15% variance on file size. When we throw
in horizontal position as well, the numbers will get much better.
I see about 27% or so when optimized just for position.

I am looking at LotionBoy's numbers, and though it shows the
same pattern as I got in my tests, the percentage variance is
quite a bit smaller. Note, his sample movie was larger.

Gotta run some tests...

[LotionBoy]

The tests were done on 1 VOB from CTHD. I'm a little puzzled by the results, though, because all rounds of the test were done on the same VOB, yet the third set of test files came out to be much larger. In the first case, I was cropping and resizing in AviSynth. For this last test, I was cropping in VirtualDub. Should be the same result, n'est pas? But it's not. very strange. I'll investigate that later tonight once I get done with my midterm and my actors.


LotionBoy

[sneeky]

More test results .. kinda what was expected.

Again, wrap up Matrix chapter5 for the moment. Moved the Vertical
window in the opposite direction and found the same pattern as in
previous test results.

Moved the Horizontal window about and it shows the same sensitivity.
Then, just did the combined "best placement window" and got the best
results as expected.


Test Procedure:

-Select chapter 5 of Matrix DVD for encoding sample.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.



Vertical window moved the other way..

Quantizer 2; tXX is top crop; bXX is bottom crop; original frame 720x480;

Data:

-720x384 t48 b48 70.7MB **
-720x384 t49 b47 62.0MB
-720x384 t50 b46 61.1MB
-720x384 t51 b45 60.0MB
-720x384 t52 b44 60.0MB
-720x384 t53 b43 60.0MB
-720x384 t54 b42 61.2MB
-720x384 t55 b41 61.9MB
-720x384 t56 b40 70.5MB **
-720x384 t57 b39 61.9MB
-720x384 t58 b38 61.1MB


Horizontal window moved around ..

Quantizer 2; crop(##,##,##,##)=(left, right,top,bottom); original frame 720x480;


-704x384 crop(8,8,48,48) 69.1MB **
-704x384 crop(7,9,48,48) 61.6MB
-704x384 crop(6,10,48,48) 60.5MB
-704x384 crop(5,11,48,48) 59.5MB
-704x384 crop(4,12,48,48) 59.2MB
-704x384 crop(3,13,48,48) 59.5MB
-704x384 crop(2,14,48,48) 60.5MB
-704x384 crop(1,15,48,48) 61.5MB
-704x384 crop(0,16,48,48) 69.3MB **


and combined best crop...

-704x384 crop(4,12,52,44) 55.9MB

[Emp3r0r]

I'm gunna squeeze a question (or three) in here...

Are you guys trying to conclude that filesize can change based on the same content, resolution and encoding method except for where you crop at or how?

I see about 27% or so when optimized just for position.
Could this be due to some kind of matrix algoritm fluke where mpeg4 methods work exceptionally well when paired up with mpeg2 source which has already been compressed?


Has anybody ran a simular test on an uncompressed source?

[LotionBoy]

I was trying to establish what the optimal resolution for encoding is, and it seems to be mod32 with all the black bars cropped. I'll do a little bit more testing on this some time later (after sleep). Sneeky is working on cropping stuff and I'm just helping out. Not quite sure what he is proving, but it seems cool. :-) me need sleep.

LotionBoy

[LotionBoy]

Okay, here is what I am going to do. I am going to take a VOB, create a couple different encode settings (like what I have done already), and then encode in Nandub to the same file size. Then analyze the DRFs to check the quality. Because they are the same VOB, comparing VOBs will give a fairly good relative measure of quality (ie, a lower average DRF is going to indicate a better looking file.) So we'll see what the results are and if cropping correctly to mod32 will really make your rips better. Going to set up the encodes now and results will be up in the morning.

LotionBoy

[duartix]

@sneeky:
Can you perform just a very very quick test under FlaskMpeg just to see if this behavior is there also? I'm not suggesting there is something wrong with the mighty tool but I wouldn't like to find out we were on a wild goose chase here.
I think I could start to see a light here.:confused: But there is something which I still dont't understand just by reading your posts. Tell me sneeky, what is the resolution of the black frame that remains after your "best placement window"?
Is it a MOD 8? Or MOD16, perhaps? This could lead to sets of completely null macroblocks at the borders which could help compression as in oposition to macroblocks with a few lines of data and a lot of them null. But if this was the case there would all but one "offending resolutions", right?. The case is that there is just one "offending :devil: resolution". Still doesn't make sense, well just a though...

I'm going through VDub's filters (like Fill Rectangle and Logo) to see if there is something that helps me create a clean source from which I can test framing and cropping...
See you...

[Zarxrax]

After reading this I've done a few tests of my own. In my tests I have not only cropped, but I have applied a precise billinear resize back to the original resolution of 720x480. Note that I used a rather short test clip, but nevertheless I think the findings are extremely interesting.

I encoded using nandub with the drfs set to 2, and bitrate 6000. Remember that I resize back to 720x480 on all the tests!

Crop 16 from both sides, 64 from top and bottom. 7.30mb
Crop 15 from both sides, 63 from top and bottom. 7.36mb
Crop 32 from all sides. 7.09mb
Crop 16 from all sides. 6.84mb
Crop 8 from all sides. 6.68mb
Crop 4 from all sides. 6.68mb
Crop 2 from all sides. 6.56mb
Crop 1 from all sides. 6.45mb
Crop 1 from top and 1 from left. 6.29mb
No crop, resize to 704x486 and resize back to 720x480. 5.51mb

Now it seems from this, that is you are going to resize your video, the optimal solution is to crop 1 from the top and left??? (resizing twice will likely cause it to get blurry.)

I'm off to try some more testing now, and apply resizes to resolutions that I actually use.

[Zarxrax]

In this test, I was using material that is 4:3. I used precise billinear resizing to resize to 640x470 for all tests.

no crop, black bars on 3 sides 5.82mb

16 on sides, 1 black bar remains 5.86mb
8 on sides, 1 black bar remains 5.87mb
4 on sides, 2 black bars remain 5.86mb
1 on sides, all 3 bars remain 5.84mb
1 on left side, all 3 bars remain 5.84mb

From this test, it would seem that the best thing to do is leave black bars on the sides of the image.


32 on top and bottom 5.06mb
16 on top and bottom 5.08mb
8 on top and bottom 5.09mb
4 on top and bottom 5.08mb
1 on top and bottom 5.07mb
1 on top 5.00mb

Now we can see here that the cropping to different values hasnt effected the results hardly at all. Cropping a single pixel from the top seems to give slightly better results than the others though. Note that all values for cropping here help to reduce the file size quite a bit from the uncropped file. This is due to the filtering from the precise billinear resize i would assume.

So it seems that the optimal solution here is (when you are working with 4:3 material) to not crop at all, and merely resize. However if you do choose to crop and then resize, the results should be about the same.
These reults seem to conflict with my last results. In the last test, note that the less I cropped (down to 1 pixel) the smaller the filesize got. Perhaps the horizontal resolutions 720 and 640 behave differently??

[LotionBoy]

of course 720 and 640 behave differently. Why? 720 is mod16 and 640 is mod32. We know that mod32 and mod16 behave differently.

Alrightie, just woke up and I got the results of my last test. Theis was in Nandub using Divx3. Encoded all the clips at the same settings. Nandub did a really good job of matching file sizes. :-)

640x352 (mod 32)
no cropping
184,119,296 bytes
AverageDRF: 2.612
Std Dev: 0.65

640x288 (mod32)
Top Crop = 44
Bottom = 43
184,119,296 bytes
AverageDRF: 2.587
Std Dev: 0.65


Crop-All on. (no black bars)

640x264 (mod32 * mod8)
top = 59
bottom = 61
184,123,392 bytes
AverageDRf: 2.552
Std Dev: 0.63

640x272 (mod32 * mod16)
top = 56
bottom = 58
sides = 5
184,123,392 bytes
AverageDRF: 2.562
Std Dev: 0.64

640x256 (mod32)
top = 64
bottom = 67
184,127,488 bytes
Average DRF: 2.441
Std Dev: 0.59

So basically, mod32/fully cropped has the best quality. The difference is not that great, probably because I used a highish bitrate, so all the clips had lots of DRF2.

LotionBoy

[ProfDrMorph]

I don't see a real rule here atm how to crop or not to crop. I think the "problem" you discovered is that the compressability is dependand on the position of the picture because the macro blocks "move".

Look at it this way: let's say you have a picture that is white on the left half and black on the right half. If there are macroblocks that cover both halfs ( some white AND some black pixels ) they will compress worse than macroblocks with only one color. By "correctly" cropping parts off the left side you could "move" those macro blocks so that they only cover one color -> file size reduce because there are hard to encode macro blocks anymore.

I think this what you've been doing all the time. This would explain why in the first test Mod32 res was best and in later tests it was not.

[sneeky]

Just some comments at this point...

Great to see lots of data...

With regards to Pattern Sensitivity, I don't know if it shows up
in all DVDs. It is interesting to note that it is really bad at
one point out of 64 possible alignments. It is marginally bad in
15 out of 64. It would be great just to make sure you don't set on
that one really bad point. (I wonder where the Pattern Sensitivity
is aligned .. upper left, center??)

I note a point that Zarxax suggests, crop one asymmetrical (1,1) on
both vertical and horizontal (move crop diagonally across frame).
That is very interesting since if you compare 2 samples done like
this, you can confirm that you do not set on the 1 really bad point.
I don't believe the samples need to be really large at this point
as I expect the pattern to reside constant throughout the DVD
(watch the studios prove me wrong). If you wanted to be sure you
didn't lie on any of the marginally bad points as well, use a 3rd
sample done offset 2,2. Pick the best sample and encode at that setting.

Once you establish you do not lie on any of the bad encoding points,
any crop setting that adds 8 will also not lie on that point. But a
crop adjustment of 4 in any setting could put you right back on the
point since 4 is half the mode of the Pattern Sensitivity.

I tested the Matrix chapter5 sample using this rule;

-704x384 (8,8,48,48) 69.1MB
-704x384 (7,9,49,47) 57.7MB
-704x384 (6,10,50,46) 56.3MB

best case:

-704x384 (4,12,52,44) 55.9MB

I would suspect if you see funny file sizes showing up using frame sizes
that are variations on MOD16 and MOD8 and not using the asymmetrical crop,
you are seeing this Pattern Sensitivity. Note that the crop moves 4 pixels
each way when varying frame size 8 pixels. This is exactly mid node of the
Pattern Sensitivity.

@Duartix

I believe the test that you want to compare "best placement window"
is interesting since the total number of lines dedicated to black
bars on the top and bottom of the frame, is the same throughout the
tests. What varies is the number of lines in the top bar, and the
number of the lines in the bottom bar, but (top bar+bottom bar) is
constant. The active picture element is about 704x356 the best I
measure. Hope that answers the question.

[duartix]

@ProfDrMorph:Look at it this way: let's say you have a picture that is white on the left half and black on the right half. If there are macroblocks that cover both halfs ( some white AND some black pixels ) they will compress worse than macroblocks with only one color. By "correctly" cropping parts off the left side you could "move" those macro blocks so that they only cover one color -> file size reduce because there are hard to encode macro blocks anymore. That's was I was talking about in my previous post when I referenced the null macro blocks and the ones with a few lines of data.

But I also pointed out that if this was the case, then there would be one alignment that would be significantely better than all the others, because the colour blocks would be separated in diferent macroblocks (null macroblocks as I called it). Now what is hapening is just the opposite: there is just this one alignment that is worse:devil: than all others. So this explanation doesn't hold off. At least not in my opinion, anyway...

I wish I had the time to test, but it's been a busy day here at work and I'm off for the girlfriend weekend, so I cant't wait until Monday when I check back what have you people found...

[LotionBoy]

if you crop off all the black in GKnot, then select Smart Crop All, and make sure both the hor. and vert. are mod32, you will get the highest quality file.

LotionBoy

[MaTTeR]

@LotionBoy

This is the way I've been testing as it made more sense to me. I'll post results later..

[ProfDrMorph]

there is just this one alignment that is worse than all others.
Maybe it's important where the edges of the macro blocks: I somewhere saw ( there are so many posts here ;) ) that the results repeated every 8 pixels. Maybe a macroblock compresses better if it start with a black line. If you crop more and more you will find alignments where the first macroblock which does contain more than black color starts with without a black line at it's top. Every 8 pixels you crop more this happens again. In between ( cropping 1-7 pixels more ) the first macroblock which contains actual picture information does start with at least one black line in it -> maybe this makes it compress better.

[BinyaminGavriel]

In a couple of posts here, I've noticed that your methods for testing include creating the dvd2avi file, then using the null transform flter in nandub to crop. However, I've been trying this with a couple of chapters from Shrek, and it seems that there is no "croppable" area (i.e., no black bars) to begin with (original res of 720x480). Therefore, I just used the resize filter to experiment with 3 different resolutions: 640x352, 576x320 and 576x304. All were encoded at same bitrate (1000), with the resulting file sizes:
640x352 -- 88,232KB
576x320 -- 88,216KB
576x304 -- 80,314KB
Questions I have on this:
1. How is it possible that the difference between the first two files is so small, but the third is so much smaller than them?
2. In general, why choose the null transform flter versus the resize filter for this experiment?
Ben

[sneeky]

@BinyaminGavriel:

In my testing, I selected to not use any filters so as to
isolate the peculiar pattern that I wanted to observe. I used
letterboxed DVDs since I can adjust the crop while always leaving
the entire movie (or at least most) the same in the encoding. From
your results, I may "assume" that this pattern is passed through
the resize filter as well, but that will need additional
data to confirm. The funny data you see is definitely symptomatic
of this Pattern Sensitivity.

@Duartix:

I was re-reading your original post on this subject, and I
assume you were trying to re-encode a Divx rip that had already
been transcoded from a DVD. Is that correct? I ask this since
your results had shown even larger sensitivities than I have
seen on a simple one pass transcode. This may indicate that
multiple re-encodes may re-enforce this sensitivity.




More movies with Pattern Sensitivity (need a better name).

Got one more movie sample coming (BraveHeart) that shows
a reversed pattern. Interesting...

All samples, so far, have exhibited this Pattern in a
8x8 matrix grid aligned the same to the original 720x480
grid.


Test Procedure:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.

Data:

Chapter5 of Blade Runner (region 1 - widescreen)
Active Picture size (654x348), remainder is black bars

Quantizer 2

move window vertical....................move window horizontal

-704x384 (08,08,48,48) 32.8MB...........-704x384 (08,08,48,48) 32.8MB
-704x384 (08,08,49,47) 29.7MB...........-704x384 (09,07,48,48) 30.3MB
-704x384 (08,08,50,46) 29.7MB...........-704x384 (10,06,48,48) 30.0MB
-704x384 (08,08,51,45) 29.2MB...........-704x384 (11,05,48,48) 29.7MB
-704x384 (08,08,52,44) 29.3MB...........-704x384 (12,04,48,48) 29.7MB
-704x384 (08,08,53,43) 29.1MB...........-704x384 (13,03,48,48) 29.8MB
-704x384 (08,08,54,42) 29.5MB...........-704x384 (14,02,48,48) 30.2MB
-704x384 (08,08,55,41) 29.6MB...........-704x384 (15,01,48,48) 30.6MB
-704x384 (08,08,56,40) 32.5MB...........-704x384 (16,00,48,48) 33.1MB

worst, best window

-704x384 (08,08,48,48) 32.8MB
-704x384 (12,04,52,44) 28.1MB


Chapter5 Space Cowboys (region 1, widescreen)
Active Picture size (720x374), remainder is black bars

Quantizer 3

move window vertical....................move window horizontal

-704x416 (08,08,32,32) 58.9MB...........-704x416 (08,08,32,32) 58.9MB
-704x416 (08,08,31,33) 56.3MB...........-704x416 (07,09,32,32) 56.9MB
-704x416 (08,08,30,34) 56.2MB...........-704x416 (06,10,32,32) 56.5MB
-704x416 (08,08,29,35) 55.7MB...........-704x416 (05,11,32,32) 56.3MB
-704x416 (08,08,28,36) 55.9MB...........-704x416 (04,12,32,32) 56.2MB
-704x416 (08,08,27,37) 55.7MB...........-704x416 (03,13,32,32) 56.3MB
-704x416 (08,08,26,38) 56.2MB...........-704x416 (02,14,32,32) 56.4MB
-704x416 (08,08,25,39) 56.4MB...........-704x416 (01,15,32,32) 56.9MB
-704x416 (08,08,24,40) 58.9MB...........-704x416 (00,16,32,32) 59.0MB

worst, best window

-704x416 (08,08,32,32) 58.9MB
-704x416 (04,12,28,36) 55.1MB

[duartix]

@sneeky:
I assume you were trying to re-encode a Divx rip that had already been transcoded from a DVD. Is that correct?
Yes. That is the exact case.

@LotionBoy
if you crop off all the black in GKnot, then select Smart Crop All, and make sure both the hor. and vert. are mod32, you will get the highest quality file.
Why? How does it work?

[BinyaminGavriel]

@sneeky:
If you don't use any filters, i don't understand how you do the cropping (In my example, BTW, although the movie [Shrek] is letterbox, when I open it up in Nandub, there are no black bars; I'll try experimenting with a different movie).
In a related question, when specifying the bitrate in Nandub, what resolution is this based on? For example, on my rip of "The Animal," I used the bitrate calculator included with Nandub, set the CD size to 700 MB, the audio size to 70 MB, and calculated the bitrate at 1035. I resized to 640x352 resolution. Now, if I were to re-encode at a different resolution, how can I detertmine by how much more I can increase the bitrate?
Similarly, how does adjusting the bitrate for the credits affect the final size?
I realize that I might be getting a little off topic, so if is would be better posted elsewhere, let me know and I'll repost as a new thread.
Ben

[LotionBoy]

Duartix

I can't answer that. I have not math to back it up. just the tests I've done, which point to that as being the optimal solution. If you can find a case where that is not true, please let me know.


LotionBoy

[Acaila]

I've followed this thread closely because some very interesting results have been showed so far. After reading it all I decided to do some tests of my own. Hence this post.

I've done a test to see what the effects of cropping the height are with certain MOD's. And what the effects of these different resolutions were when resized to a correct aspect ratio compatible resolution (704x288).
I didn't crop the width, because for most movies this isn't needed anytway.


Test conditions:
Movie: Pearl Harbor (500 frames somewhere in the middle)
Codec: Xvid 1-pass quality 100%
Original Resolution: 720x576 (PAL 16:9)

Crop Width Height H-MOD Size(MB) After Resize(MB)
0 720 576 32 25,4 16,5
4 720 568 8 29,4 16,9
8 720 560 16 26,5 17,3
12 720 552 8 29,4 17,7
16 720 544 32 25,3 17,8
20 720 536 8 29,4 18,0
24 720 528 16 26,5 18,2
28 720 520 8 29,4 18,4
32 720 512 32 25,3 18,8
36 720 504 8 29,4 19,0
40 720 496 16 26,4 19,4
44 720 488 8 29,4 19,8
48 720 480 32 25,3 20,0
52 720 472 8 29,4 20,3
56 720 464 16 26,4 20,6
60 720 456 8 29,4 20,9
64 720 448 32 25,3 21,3
68 720 440 8 29,4 21,5
72 720 432 16 26,2 21,5
Between these values the black bars end and the movie begins
76 720 424 8 28,9 21,7
80 720 416 32 24,3 21,6
84 720 408 8 27,8 21,6
88 720 400 16 24,4 21,7


Some things definately stand out:
While in the black area, size remains constant no matter how much you crop when you stay with equal H-MOD's. H-MOD 32 seems an absolute must to get the smallest file.
After you've cropped all the black bars, cropping further into the image (still talking about not resizing) starts to decrease filesize with equal H-MOD's.
When you resize, the original cropped resolution becomes irrelevant, except that the more black remains in the frame the smaller the file is. This seems logical because black can be compress much better than color. No relation to H-MOD is visible anymore.
When you resize, after all black bars have been cropped out of the frame the filesize remains constant no matter how much of the actual movie is cropped away. Filesize would probably depend on resize resolution at this point.

Based on the cropping-only results I would conclude to always crop to H-MOD 32 resolutions. However after I did the resizing it seemed that the cropping didn't matter anymore...

I'd love to hear some opinions/comments on this.

[sneeky]

@Acaila:

I find you results reaffirming. I note the exact period in
the compression sizes before resize is exactly what I have
seen. The difference in my samples up to now, if tested as you
test, MOD8 repeats as best size instead of worst size. Don't
fret over this as I have more data showing the pattern you
have seen as well. It seems to exist as a +/- syndrome. But
always aligned on grid of 8x8. I have preliminary results
indicating that bilinear resize destroys the pattern
sensitivity like you observe in your tests.

One question though. Did you use bilinear or bicubic resize?
Neutral or sharp if bicubic?

[sneeky]

Another Movie with Pattern Sensitivity...

The interesting thing about this sample is that it demonstrates an
opposite mode compared to the previous samples. This suggests a few
things.

1. A different matrix alignment mode in the encoding process. I find
this to be less probable due to the nature of encoding process.

2. Some pre-encoding process/filter that can influence the the
encoding process in a +/- fashion. I find this more probable. This
could also explain the wide variations in the Pattern Sensitivity.
(suspects.. sharpness?)

I note that the 3 movie samples exhibiting the same Direction
Pattern Sensitivity were all Warner Bros. releases. The BraveHeart
sample here, that shows the opposite direction Pattern Sensitivity, is
a Paramount release.

Test Procedure:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.

BraveHeart, chapter11 (region1, widescreen)
Active Picture size (720x360), remainder is black bars

Data:

Quantizer 3

move window vertical....................move window horizontal

-704x384 (08,08,48,48) 401.7MB..........-704x384 (08,08,44,52) 408.5MB
-704x384 (08,08,47,49) 404.4MB..........-704x384 (07,09,44,52) 410.3MB
-704x384 (08,08,46,50) 406.5MB..........-704x384 (06,10,44,52) 410.8MB
-704x384 (08,08,45,51) 406.5MB..........-704x384 (05,11,44,52) 410.5MB
-704x384 (08,08,44,52) 408.5MB..........-704x384 (04,12,44,52) 411.5MB
-704x384 (08,08,43,53) 406.5MB..........-704x384 (03,13,44,52) 410.2MB
-704x384 (08,08,42,54) 406.7MB..........-704x384 (02,14,44,52) 411.5MB
-704x384 (08,08,41,55) 405.3MB..........-704x384 (01,15,44,52) 410.5MB
-704x384 (08,08,40,56) 403.3MB..........-704x384 (00,16,44,52) 408.4MB

worst, best window

-704x384 (08,08,48,48) 401.7MB
-704x384 (04,12,44,52) 411.5MB

[Acaila]

@Sneeky:
I used Sharp Bicubic for the resize.

My guess is that resizing destroys any pattern that resulted from cropping. Any kind of resizing.
It's possible that the different resizing methods result in patterns of their own, which override the crop-pattern.

Have you tried different resizing methods on samples that were cropped the same, and did you see a pattern evolving?

[duartix]

What's funny about this is that in my tests, which were second generation rips, the Patrix (the Pattern Matrix :scared: ) has always given me bigger differences than yours:

.............Horiz. MODS..........
CODECS....M32.....M16......M8
divx3..........0%....+36%....+57%
DivX4........-1%....+23%....+35%
XVid.........-5%....+23%....+32%
Acaila Test
XVid...........0%.....+4%....+16%

So why is it far worse with second generation rips? Five minutes (yeah right) please, so I can test something...

I've just bloody wasted down about half a bloody hour and my post just because of this bloody board and my frustrated atempts to align the bloody text.:mad: :mad: :mad:

Well, to sum it up:
Source: Same Bruce Lee's Rip.
Codec: divx 3.11.
Keyframes every second. (With a purpose)
NO = 352 height (no crop)
M32 = 352-16-16
M16 = 352-8-8
M8 = 352-4-4
Results are filesizes in KB of Key frames and Delta frames.

KFrames:
NO......257
M32....258...(+0%)
M16....259...(+1%)
M8......270...(+5%)

DFrames:
NO......2639
M32....2648...(+0%)
M16....3678...(+39%)
M8......4554...(+73%)

Well it didn't turned out quite what I expected (KF size constant) but you can see that DF suffered big time. I can't begin to guess what to blame, if the textures or the motion vectors, but now that I think about it, I would sure put my money on the motion vectors because and just because the KF size didn't raise as much, and I suppose KF are nothing but texture data...

[avih]

i'm breathless. just read the thread from it's start :)

regarding 2nd generation encoding (encoding from dvd falls into this category, albeit with lesser effect - very high bitrate mpeg2)

the source (beeing already encoded) contains sharp edges on blocks (8x8) bounderies. hence deblocking is often needed for playback.
when re-encoding, deblocking isn't applied. i suspect that even if that artefact isn't extremely visible, it has a strong effect on compresability *** if these sharp edges are positioned INSIDE (instead of between) the blocks of the newly encoded clip. ***

this, since the mpeg-4 compresses each block (8x8) seperatelly, and if a block contains hi frequencies (=sharp edges) inside it, it uses considerably more bits.

naturally, when re-encoding an already highly compressed clip (from divx/xvid/other block based) the effect is amplified since this blocking is more noticable..

the black-bars, kinda falls into the same category. blocks which are entirely black, are VERY compressible, however, all blocks wich are partially black consume more bits because of the sharp edge (black->movie).


one posible sourse of trouble and inconsistant results might be the fact that <b>black border edges might not align with original mpeg-2 blocks or with eachother</b>

hence moving the crop window (with black border) vertically might align top-black-border, and misalign mpeg-blocks and/or bottom-black border or other similiar ways -> inconsistant results.

thus, when conducting these test, imho, black borders should be cropped completely (at least MOD8) (including the top-most movie line and bottom-most movie line, just to be on the safe side).

now moving the window will effect only the block allignment issue (of re-encoded clip).

same applies to horiz cropping (are there right/left black borders on a dvd??)

i hope there's some sence in what i'm saying here. just my 2 cents.

side note: yes, resizing does effect compressibility considerably, therefore, i think all tests should be done without resizing at all. that takes out one more factor from this mess :)



regards
avi

ps
fascinating thread :)

ps2
i would have done some testing myself, but i don't have dvd-rom :(

[FH2]

Originally posted by ChristianHJW

Next thing i'd like to know is what happens if you cut away the black bars from the original pic ( as precisely as possible ) and resize to a picture being multiples of 32 pixel in width and height, even if aspect ratio is screwed this way ? We could compare to another encoding with same width ( 32 ) but height being 8 or 16 pixels smaller. The number of total pixels is of course higher in 1st case but not much and its interesting to learn about filesizes.


I did something like that. I've taken a File which had full DVD resolution (720x576) and I cutted away the black bars. In the first test, I've set the horizontal resolution to 512 and the vertical resolution between 256 and 320. (first table). In the second test I've set the vertical resolution at 288 and the horizontal resolution between 480 and 544. (second table)

Both time I used XviD (Koepi's Build from 12.03.2002) and Virtual Dub using 1-Pass-Quality Mode set to 100%. Here the results:
http://mitglied.lycos.de/semonilion/xvid_32.jpg

Comment to the first test: I could see no difference between a resolution being a multiple of 16 or 32. But using a multiple of 8 (which is not a m. of 16 or 32) doesn't take much less space as if you give it another 8 pixels.

Comment to the second test: Also here no difference between 16 and 32. But in this case, i takes much more space if you don't any of these multipliers.

P.S. sorry for the bad english, i try my best to make it understandable for everyone.

[crAss]

Well one thing came into my mind after reading this thread. Let's take as granted that we are resizing the film.
What if we crop exactly where the black bars are so the pixel isn't MOD8, MOD16 or MOD32, and then resize the film at a resolution that is MOD32. Are we going to see the same results posted here???
I will do some testing

crAss

[trbarry]

the source (beeing already encoded) contains sharp edges on blocks (8x8) bounderies. hence deblocking is often needed for playback.
when re-encoding, deblocking isn't applied. i suspect that even if that artefact isn't extremely visible, it has a strong effect on compresability *** if these sharp edges are positioned INSIDE (instead of between) the blocks of the newly encoded clip.

Does this mean we should all be running some sort of deblocking filter in DVD2AVI or Avisynth or something?

For instance I wonder if recoding XviD files using deblocking in Nic's xvid.ax as a DirectShowSource input to Avisynth would correct this.

- Tom

[avih]

tom, i was marely suggestive.
i didn't say it IS the problem, just mentioned that by moving the clipping window, u MIGHT have 3 different minima alignments (per axis): i.e. on the vert axis:
one for top black border
one for bot black border
one for blocks of original encode

of course, as the clip is of higher quality (as dvd's are) the 3rd alignment problem is somewhat diminished.

also, if applying deblocking does reduce the size, it doesn't neccesarily mean that it's the blocks that caused the oversize. that, since the deblocking filter is not optimal, and filters anyway, regardless (with some respect actually) of actual blocking artefacts. and it's a known fact that filtered clips produce smaller sizes.

cheers
avi.

ps.
GREAT work on nic's ds filter. ;) !

[sneeky]

OK, so I am slow to getting the data out. I hate the task of doing the
matrix of testing. But I chose the Blade Runner movie sample because it
has black bars all around, both sides and top & bottom.

I tested looking for re-encoding (3rd generation) pattern sensitivity.
I find this to be the most interesting aspect of this issue. If you were
to use these types of codecs for capture, and subsequently wish to do
any "Non-Linear Editting" (NLE), than you can expect to encounter this
issue quite a bit. Some data indicates that resizing destroys this
sensitivity, and maybe other filters do too. But this substantiates
Duartix's original observation.

The data is composed of the ORIGINAL TEST on this movie sample as
transcoded from the DVD. Then, specific "worst/best" case samples were
selected for study. The worst/best samples were trancoded from the original
DVD source and this created the 2nd generation sample to be re-encoded,
creating a 3rd gen sample. To expose the pattern sensitivity, the crop
window was moved diagonally, pixel by pixel across an 8x8 matrix. I used
a diagonal crop movement since it exposes the same pattern sensitivity
with less data. In all cases, the active movie area is always the same
because all the cropping takes place in the black bar areas.

The results indicate a greater pattern sensitivity in the 3rd generation
encode (the re-encode) than the 2nd generation (the transcode).

The 1st generation is the DVD.
The 2nd generation showed "worst/best" of 32.9MB/28.2MB = 117%.
The 3rd generation showed "worst/best" of 26.0MB/19.3MB = 135%.

TEST PROCEDURE:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed.
==================================================

DATA:
==================================================

Chapter5 of Blade Runner (region 1 - widescreen)
Active Picture size (654x348), remainder is black bars
Crop numbers are (##,##,##,##)=(left, right,top,bottom)
Quantizer 2 all samples.


==================================================

ORIGINAL TEST DATA showing pattern sensitivity...

move window vertical .................. move window horizontal

-704x384 (08,08,48,48) 32.8MB ......... -704x384 (08,08,48,48) 32.8MB
-704x384 (08,08,49,47) 29.7MB ......... -704x384 (09,07,48,48) 30.3MB
-704x384 (08,08,50,46) 29.7MB ......... -704x384 (10,06,48,48) 30.0MB
-704x384 (08,08,51,45) 29.2MB ......... -704x384 (11,05,48,48) 29.7MB
-704x384 (08,08,52,44) 29.3MB ......... -704x384 (12,04,48,48) 29.7MB
-704x384 (08,08,53,43) 29.1MB ......... -704x384 (13,03,48,48) 29.8MB
-704x384 (08,08,54,42) 29.5MB ......... -704x384 (14,02,48,48) 30.2MB
-704x384 (08,08,55,41) 29.6MB ......... -704x384 (15,01,48,48) 30.6MB
-704x384 (08,08,56,40) 32.5MB ......... -704x384 (16,00,48,48) 33.1MB

worst, best window

-704x384 (08,08,48,48) 32.8MB
-704x384 (12,04,52,44) 28.1MB
==================================================


RE-ENCODE TESTING ... 2nd generation ==>> 3rd generation ...
---------------------------------------------------------------

Transcode at worst sample matrix alignment... 2nd generation

Transcode (2nd gen) worst sample ...... -704x448 (08,08,16,16) 32.9MB

3rd gen Crop Numbers (##,##,##,##) refer to 2nd gen sample ...
Re-encode (3rd gen) matrix sample...... -688x416 (08,08,16,16) 26.0MB
....................................... -688x416 (09,07,17,15) 22.1MB
....................................... -688x416 (10,06,18,14) 22.3MB
....................................... -688x416 (11,05,19,13) 21.9MB
....................................... -688x416 (12,04,20,12) 22.3MB
....................................... -688x416 (13,03,21,11) 21.9MB
....................................... -688x416 (14,02,22,10) 22.4MB
....................................... -688x416 (15,01,23,09) 22.2MB
....................................... -688x416 (16,00,24,00) 26.1MB

---------------------------------------------------------------

Transcode at best sample matrix alignment... 2nd generation

Transcode (2nd gen) best sample ....... -704x448 (12,04,20,12) 28.2MB

3rd gen Crop Numbers (##,##,##,##) refer to 2nd gen sample ...
Re-encode (3rd gen) matrix sample...... -688x416 (08,08,16,16) 22.4MB
....................................... -688x416 (09,07,17,15) 19.7MB
....................................... -688x416 (10,06,18,14) 19.9MB
....................................... -688x416 (11,05,19,13) 19.3MB
....................................... -688x416 (12,04,20,12) 19.6MB
....................................... -688x416 (13,03,21,11) 19.3MB
....................................... -688x416 (14,02,22,10) 19.9MB
....................................... -688x416 (15,01,23,09) 19.7MB
....................................... -688x416 (16,00,24,08) 22.4MB

==================================================

[sneeky]

I didn't put this in the post above since that post contains
test info.

@Duartix

I note your previous test indicating that I-frames show less
pattern sensitivity, or at least thats what I conclude you are
trying to point to. I find this curious too. But now that means
alot more detail testing to corroborate. Thanks for making this
difficult.

It would be a nice follow-up to just do the worst/best case samples
from the above test using I-frames only. I'll see what I can do.

[sneeky]

Used the Blade Runner chapter5 DVD sample.
Tested several conditions looking for pattern sensitivity.
Used diagonal crop window scan technique on 8x8 matrix.

Summary:

=>@ Q=2, tested 2D Cleaner filter (1 dimension). Worst/Best = 24.5MB/23.4MB = 105%

=>@ Q=2, tested 2D Cleaner filter (2 dimension). Worst/Best = 21.2MB/21.1MB = 100%

=>@ Q=2, I-Frames only . Worst/Best = 77.8MB/74.4MB = 105%

=>Tested @ Q=5. Worst/Best = 6.67/6.07 = 110%



TEST SAMPLE:

Chapter5 of Blade Runner (region 1 - widescreen)
Active Picture size (654x348), remainder is black bars
Crop numbers are (##,##,##,##)=(left, right,top,bottom)


TEST PROCEDURE:

-Select DVD video sample for encoding.
-Create DVD2AVI (720x480) project without cropping and feed to VirtualDub 1.4.8.
-Use Null Transform filter to perform various crops.
-Encode using Xvid CVS 02-27-02 codec (source=Nic).
-Use "one pass - quantizer" mode.
-Record each encoding session file size.

-No resize or other filters allowed UNLESS NOTED!!!!
====================================================

DATA:
====================================================
Used Jim Casaburi's 2d Cleaner, settings one dimension x=1, y=0, T=10
Fixed Quantizer=2

-704x448 (08,08,16,16) 24.5MB
-704x448 (09,07,17,15) 23.5MB
-704x448 (10,06,18,14) 23.6MB
-704x448 (11,05,19,13) 23.4MB
-704x448 (12,04,20,12) 23.6MB
-704x448 (13,03,21,11) 23.4MB
-704x448 (14,02,22,10) 23.6MB
-704x448 (15,01,23,09) 23.5MB
-704x448 (16,00,24,08) 24.5MB

----------------------------------------------------------------------
Used Jim Casaburi's 2d Cleaner, settings two dimension x=1, y=1, T=10
Fixed Quantizer=2

-704x448 (08,08,16,16) 21.2MB
-704x448 (09,07,17,15) 21.1MB
-704x448 (10,06,18,14) 21.2MB
-704x448 (11,05,19,13) 21.1MB
-704x448 (12,04,20,12) 21.2MB
-704x448 (13,03,21,11) 21.1MB
-704x448 (14,02,22,10) 21.2MB
-704x448 (15,01,23,09) 21.1MB
-704x448 (16,00,24,08) 21.2MB

----------------------------------------------------------------------
Fixed Quantizer=2, I-Frames only

-704x448 (08,08,16,16) 77.8MB
-704x448 (09,07,17,15) 75.1MB
-704x448 (10,06,18,14) 75.2MB
-704x448 (11,05,19,13) 74.4MB
-704x448 (12,04,20,12) 75.2MB
-704x448 (13,03,21,11) 74.5MB
-704x448 (14,02,22,10) 75.2MB
-704x448 (15,01,23,09) 75.0MB
-704x448 (16,00,24,08) 77.8MB

----------------------------------------------------------------------
Fixed Quantizer=5

-704x448 (08,08,16,16) 6.67MB
-704x448 (12,04,20,12) 6.07MB