Steps to take for proper cropping

[Xoemab]

I heard that sometimes its better not to cut completely the black borders because there is other important factor. So what it is? I have now one video 1920x1080 video and megui suggest me to cut 220 left and 220 right, but I see that to cut completely black borders I must cut 222 left and 220 right. So I must trust completely megui? Or we are both wrong?

[LoRd_MuldeR]

Technically, YUV 4:2:0 can not be cropped to anything but mod-2 (i.e. the number of remaining pixels must be an even number). But that's it.

Internally, most video formats (including H.264) work on 16x16 blocks, so your input will internally be padded to mod-16, if it's not mod-16 already.

But there is nothing to worry about. Some sources suggest you should always crop to mod-16, but that doesn't apply to modern encoders!

Overall, I think your video will compress much more efficiently when cropping away that "black border" entirely, even if that results in a non-mod-16 resolution.

(The overhead for the internal padding should be much smaller than the overhead that you'd get for encoding the sharp black border)

[Marin85]

So I must trust completely megui? Or we are both wrong?
Trust your eyes only. Whatever you see in AvsPmod, that is it. The only issue would be if you have to crop an odd number of pixels on a side, in which case there are several different views on how to proceed.

[MeteorRain]

Cut all the black part away. Keep both left and right crop even. That's it.

[M+AUDIO]

Hello.
So to clear above discussion up for myself,

Are those internally padded parts also needs some bitrate (losses bitrate?)

[Blue_MiSfit]

Just crop the black border entirely. Don't worry about any overhead of coding non mod-16. Seriously, don't worry about it :)

[LoRd_MuldeR]

Hello.
So to clear above discussion up for myself,

Are those internally padded parts also needs some bitrate (losses bitrate?)

There will be some pixel added to make the video mod-16 and these will be cropped away at playback time. So you are actually encoding some pixels that you will never see. This causes a certain overhead. BUT: Because you will never get to see the "padding" pixels, the encoder can choose them freely. And modern encoders will generate the padding pixels in a way that makes them "cheap" to compress. So you shouldn't worry much about that! What would be the alternative? If you crop away fewer pixel in order to make your video mod-16, you will end up with a sharp black border, which is "expensive" too encode! And if you crop away more pixels in order to make your video mode-16, you'll loose some of the actual content...

(Edit: Blue_MiSfit was faster ^^)

[hello_hello]

AutoCropping is fairly rough. I use MeGUI's autocropping and then invariably end up adjusting it manually to make the edges nice and clean, then I resize, and more often than not adjust cropping again in some way to get the aspect ratio distortion as close to zero as I can.
I don't mind losing a few extra pixels of actual picture if it stops it from being distorted if it's resized, but I also like nice sharp edges, so I always crop away all the "crud".

I generally try to use a mod4 width. The height doesn't seem to matter. That's not for encoding reasons though. I have my PC connected to my TV, so I like to save scripts, open them with MPC-HC, and use it to display the video running fullscreen on my TV to see how it looks before I start encoding. For reasons I don't understand, if the width is mod2 MPC-HC can't open the scrpts. Instead I get and AVISynth error along the lines of "YV12 images for output must have a width divisible by 4". mod2 widths still display correctly in MeGUI's preview though and the encoded video has never caused a playback issue because the width is mod2.
Or if I want a mod2 width I save the script, manually change the resizing to a mod4 width, preview it with MPC-HC, then change the resizing back again for encoding.


On the subject of mod16 vs non-mod16 and black borders.....
I ran some test encodes using mod16 and non-mod16 a while back, and also while manually adding a black border to see how each effected the bitrate/file size in CRF mode. It was part of a discussion in another forum a while back, but this is what happened (x264 slow preset, CRF18). The video was cropped the same way each time, just resized slightly differently.

Resized to 640x480: 626.8MB
Resized to 640x482: 645.8MB
Resized to 640x480 with 16 pixels worth of black border at the bottom to output 640x496: 629.6MB
Resized to 640x482 with 14 pixels worth of black border at the bottom to output 640x496: 632.3MB
Resized to 640x482 with 16 pixels worth of black border at the bottom to output 640x498: 632.6MB
Resized to 640x484 with 14 pixels worth of black border at the bottom to output 640x498: 634.1MB

And to test the bitrate required to encode nothing but black, I encoded an hour of black at a resolution of 1024x144 using x264's default settings and CFR18. The output file size was 2.1MB.

So a height of 482 required a slightly higher bitrate than a height of 480, but that's what you'd expect anyway.
If the picture is mod16 and you add a mod16 black border, the bitrate also increases a little, as you'd expect.

If you take a non-mod16 picture and add a black border, the bitrate reduces a little even though there's effectively more video to encode, but maybe that just means it takes less bitrate for the encoder to encode a "real" black border than it does to add it's own "padding".
I suspect though, if the picture is non-mod16 and you add a black border, it's presence slightly effects how the picture itself is encoded.

Anyway.... the upshot of my test encodes led me to conclude none of it really matters. Crop the way you want to, use mod16 or non-mod16, crop away the black borders completely or keep them.... none of it effects the bitrate/file size enough to matter.

[hello_hello]

If you crop away fewer pixel in order to make your video mod-16, you will end up with a sharp black border, which is "expensive" too encode!

You sure about that?
Part of the original discussion which led to my running the test encodes above, involved the theory that if you keep black borders they should be mod16, so you should always crop them to leave a mod16 picture with nice sharp edges, then add them back. Which is why when running the encodes above, I cropped them the same way each time and added a border manually. Having a nice sharp edge didn't seem to increase the bitrate. Even having a nice non-mod16 sharp edge didn't make much difference, aside from actually reducing the bitrate a bit.

Plus I'm certain at some stage I've encoded a video with "blurry" borders.... the type which doesn't have a sharp edge between picture and border, then decided it was annoying me, cropped the "blurry" border and replaced it to give it a nice sharp edge, and doing so reduced the bitrate a little bit.

These encodes were part of the same discussion I mentioned in my last post (http://forum.videohelp.com/threads/353220-Why-do-most-people-crop-out-the-black-bars-when-ripping-a-DVD?p=2219903&viewfull=1#post2219903), but this time I encoded an hour of 16:9 DVD video with and without black bars top and bottom. Cropping stayed the same, resizing changed a little.

1024x436 (mod4 height) produced a file size of 810.0 MB
1024x432 (mod16 height) produced a file size of 810.6 MB
1024x576 (black borders added back) produced a file size of 800.2MB
1024x144 (nothing but black) produced a file size of 2.1MB

The encode which resulted in the lowest bitrate was the one with black borders, even though the difference wasn't anything to get excited about, but the above results would tempt you to assume the 1024x576 encode should have been the largest by 2 or 3 MB, instead of being 10MB smaller.
I never did understand why the second encode didn't result in an output file size slightly smaller than the first instead of being a little larger. Maybe the slightly different resizing effected how easily it could be compressed in negative way, more than the positive effect the slight reduction in resolution would have had.

[Asmodian]

Remember the effect of a resize filter can be quite significant, if you want to test like this you need to not change the resize at all. Only adjust cropping.

But these are already interesting results. I wonder what happens if you "scan" the 1024x432 frame from 64 black on top with 80 on the bottom to 72 on top 72 on the bottom in 2 pixel steps (4 encodes). I do not see how adding 72 pixels of black to the top and bottom of the frame reduced the file size unless it also reduced the quality.

[LoRd_MuldeR]

@hello_hello:

You are comparing file sizes, but how did you get them? CRF mode with same CRF value?

If so, I think CRF mode is not really suitable for this kind of test. By adding black borders, for example, you change the content quite a lot. So you might end up comparing apples and oranges.

I think you should either use 2-Pass mode (with same bitrate) and actually compare visual quality. Or you use constant QP mode...

[UPDATE]

Here is a quick test: I created a clip of size 720x544 (mod-16), containing 2-lines of black pixels at the top and at the bottom each.

If I keep the black borders in, so that the clip remains mod-16, it comes out at 57.613.580 bytes. Now, if I crop away the black borders to 720x540, which makes the clip mod-4, it comes out at only 57.539.626 bytes.

Not a very big difference, but it shows that the "padding" pixels are cheaper to encode than the black pixels (and the resulting sharp border). Both clips were encoded with CQ-mode and QP=20.

[hello_hello]

I did figure the black borders might effect the way the actual picture was encoded a little in CRF mode, but I don't think it's enough to worry about. And I was testing CRF mode as that's what I use, although I guess maybe testing in CQ mode would have provided additional information too.

How's this for a "black borders" vs "padding" test?
For the short test encodes below (3 minutes 20 seconds), the entire video was nothing but black. I used x264's defaults each time (CRF23, or CQ23).

640x480, CRF23, 152514 bytes
640x476, CRF23, 152515 bytes

640x480, CQ23, 144903 bytes
640x476, CQ23, 144904 bytes

So far..... the cost of encoding black borders and using padding seem fairly similar.

A "sharp edges" test? This time, the entire video is 640x476 worth of white.

Encoded at 640x476
CRF23 152515 bytes
CQ23 144904 bytes

Adding a 4 pixel black border to the bottom to encode at 640x480.

CRF23 155711 bytes
CQ23 145198 bytes

Okay, granted when you encode a black border and the rest of the picture isn't, the cost does seem to increase a little, whereas the price of padding doesn't, but it still seems pretty affordable. ;)

So I guess the question remains.... why did my previous tests of closer to "real world" encodes indicate black borders could decrease the bitrate in CRF mode. At least when the picture itself isn't mod16. I guess the only possibility is borders can cause the picture quality to decrease a little for a given CRF value.