width is not mod16, should I resize to mod16 before encoding, or not?

[codemaster]

I'm using x264 to encode a video that has a width of 702 pixels. I have two options:

1. To resize in AviSynth from 702 px to 688 px, and then encode with x264 (x264 will encode frames which have a width of 688 px).
2. To not resize in AviSynth, and encode with x264 (x264 will encode frames which have a width of 702 px).

Which of the above two option would you recommend?

[manono]

688? Why not 704? Anyway, I believe x264 can encode the 702 with no problem. Not so sure about all playback devices, though.

How did it get this width of 702 in the first place? That's what was left after you cropped away the black? If it were I, I'd crop to 704 and then use BorderControl to cover up the remaining thin black strip.

[codemaster]

Ok, then I'll crop 8 px instead of 9 px, so that width will be mod16 (704 px). I wanted to crop 9 px instead of 8 px, because the black bars are exactly 9 px, and because it preserves aspect ratio more precisely (by not being 2 px less wider that 16:9). But I noticed that experts in video compression suggest not to use non mod16 width. I wasn't sure if there could be issues with playing or encoding video which has width of 702 px.

[LMotlow]

Ok, then I'll crop 8 px instead of 9 px, so that width will be mod16 (704 px). I wanted to crop 9 px instead of 8 px, because the black bars are exactly 9 px, and because it preserves aspect ratio more precisely (by not being 2 px less wider that 16:9).

Ewww! Ouch! Yikes!
Cropping YUV pixel width with odd numbers! Man, that hurt! Is this for real? Are you using YV24 or something?
http://avisynth.nl/index.php/Crop

[Marsia Mariner]

But I noticed that experts in video compression suggest not to use non mod16 width.

That info is quite outdated.
Unless your hardware video player is very ancient or/and picky, there is no reason to enforce the mod16 rule.
Software decoders and encoders require the frame dimensions to be mod2, except for MPEG-1 and MPEG-2, which require mod8.

IIRC, AutoGK enforced mod16, but that always was an artificial limitation.
And until recently, HCenc "disrespected" the mod16 thing only when the video height was 1080.

[LMotlow]

Mod4 at least, Marsia. I know you never heard of Avisynth, but if you do (fat chance) and you see the green screens it's because many filters require mod8. Did someone from BestBuy sell you a player and tell you it really grooved on mod-2 material, guar-rawn-teed, fo' sho', or your money back.

Where do these fictions come from?

[jagabo]

I still occasionally see devices that can't handle mod2 h.264 or Divx/Xvid. I'd stay with mod4 to be safe.

[_Al_]

Common mistake to get rid of tiny black bars or columns at all cost. But internet is full of scripts like that (even crop, resize and similar woo-doo) so folks are going to do it again and again.

[codemaster]

Ok, then I'll crop 8 px instead of 9 px, so that width will be mod16 (704 px). I wanted to crop 9 px instead of 8 px, because the black bars are exactly 9 px, and because it preserves aspect ratio more precisely (by not being 2 px less wider that 16:9).

Ewww! Ouch! Yikes!
Cropping YUV pixel width with odd numbers! Man, that hurt! Is this for real? Are you using YV24 or something?
http://avisynth.nl/index.php/Crop

I'm using YV12. Thanks for the URL, I wasn't aware that there are crop restrictions to "preserve the data structure of the colorspace".

For YV12 colorspace, the crop restriction for width is mod-2. Forum member jagabo says he saw devices that can't handle H.264 with mod-2 resolution. And I'm encoding to H.264, and I don't want any playback issues on any device.

I have these 3 options:

Option 1. If I crop 8 pixels from the left, and 8 pixels from the right:
- resolution is 704x576;
- resolution is mod-16, which is good for the encoder because it works with macroblocks of 16x16 pixels;
- resolution is mod-2 and scan type is progressive, which conforms with crop restrictions for the YV12 colorspace;
- the video will be 2 pixels less wider than 16:9;
- vertical black bars are not cropped completely;
- devices will not have playback issues.

Option 2. If I crop 9 pixels from the left, and 9 pixels from the right:
- resolution is 702x576;
- resolution is not mod-16, but modern encoders support non mod-16 resolutions with minimum overhead;
- resolution is mod-2 and scan type is progressive, which conforms with crop restrictions for the YV12 colorspace;
- aspect ratio will be exactly 16:9, instead of 2 pixels less wider that 16:9;
- vertical black bars are cropped completely;
- some devices will have playback issues.

Option 3. If I crop 8 pixels from the left, and 8 pixels from the right, and then resize to the closest mod-16 resolution:
- resolution will be 688x576;
- resolution is mod-16, which is good for the encoder because it works with macroblocks of 16x16 pixels;
- resolution is mod-2 and scan type is progressive, which conforms with crop restrictions for the YV12 colorspace;
- aspect ratio will be exactly 16:9, instead of 2 pixels less wider that 16:9;
- vertical black bars are cropped completely;
- devices will not have playback issues.

I won't choose option 2. Between option 1 and 3, I don't know which one to choose. For me, it's a dilemma. I'll use option 1 now, and if and when I change my mind, I'll use option 2.

But what would you choose? Would you rather have vertical black bars that are 1 pixel wide and an aspect ratio 2 pixels less wider than 16:9, than cutting 9216 pixels of detail? Or would you rather throw away 9216 pixels of detail just to have an aspect ratio that is not 2 pixels less wider than 16:9, and to not have vertical black bars that are 1 pixel wide?

[hello_hello]

Ewww! Ouch! Yikes!
Cropping YUV pixel width with odd numbers! Man, that hurt! Is this for real? Are you using YV24 or something?
http://avisynth.nl/index.php/Crop

Don't forget you can use the resize filters for single pixel cropping. You still have to resize to at least mod2, but to crop 4 pixels from the left and 5 from the right:

Spline36Resize(704,396,4,0,-5,0)
or
Crop (4,0,-4,0)
Spline36Resize(704,396,0,0,-1,0)

Mod4 at least, Marsia. I know you never heard of Avisynth, but if you do (fat chance) and you see the green screens it's because many filters require mod8. Did someone from BestBuy sell you a player and tell you it really grooved on mod-2 material, guar-rawn-teed, fo' sho', or your money back.

Where do these fictions come from?

I'll confess aside from one of the old logo removal scripts I use which enforces mod4 for the logo area (RMLogo or InPaintFunc) none of the Avisynth filters I use require mod8, or even mod4.

I regularly use mod4 for standard definition because the dimensions are exactly 16:9 or 4:3.
960x540, 704x396, 720x540, 624x468 etc. I can't remember the last time I had problems playing a mod2 video on anything, but when encoding I play it safe and stick to mod4 because jagabo's made me mod2 paranoid.

Even iTunes video comes as mod2 occasionally (it's mentioned in a post here). and often mod4. The naughty web-dl torrents are mostly from iTunes minus any DRM. Try Googling "web-dl 1280x718".

[jagabo]

Even iTunes video comes as mod2 occasionally.

Apple only cares about the video playing on their hardware and software -- an ecosystem that they control.

[hello_hello]

Common mistake to get rid of tiny black bars or columns at all cost. But internet is full of scripts like that (even crop, resize and similar woo-doo) so folks are going to do it again and again.

If you're encoding anyway, cropping tiny black bars is hardly a mistake, it's personal preference. If you're encoding anyway, to me it seems almost stupid to pass on the opportunity.
Are you having a go at my script again because you still don't understand many people prefer to crop and resize to specific dimensions (ie 16:9 or 4:3)?

That reminds me.... I created a wrapper function for the script to make it easier to use. I've been meaning to add it to the CropResizeBorder thread. I should do that later.

[manono]

Option 3. If I crop 8 pixels from the left, and 8 pixels from the right, and then resize to the closest mod-16 resolution:
- resolution will be 688x576;

For the second time now, the closest Mod16 resolution is 704x576.

Option 1. If I crop 8 pixels from the left, and 8 pixels from the right:

- vertical black bars are not cropped completely;

And I mentioned already that one easy way to cover it up is with the use of BorderControl. If the black is on the left side:

BorderControl(XLS=2,XLSF=2)

If it's on the right side replace the 'L' with 'R'.

[codemaster]

one easy way to cover it up is with the use of BorderControl

Thanks for the suggestion, I'll crop from 720x576 to 704x576 and use BorderControl() to disguise the 1 px vertical black bars, as an alternative to cropping 720x576 to 704x576 and then resizing from 704x576 to 688x576.

[_Al_]

Common mistake to get rid of tiny black bars or columns at all cost. But internet is full of scripts like that (even crop, resize and similar woo-doo) so folks are going to do it again and again.

If you're encoding anyway, cropping tiny black bars is hardly a mistake, it's personal preference. If you're encoding anyway, to me it seems almost stupid to pass on the opportunity.
Are you having a go at my script again because you still don't understand many people prefer to crop and resize to specific dimensions (ie 16:9 or 4:3)?

That reminds me.... I created a wrapper function for the script to make it easier to use. I've been meaning to add it to the CropResizeBorder thread. I should do that later.

please, not again
its simple, if op did it himself, he could resize to 16:9 or 4:3 (whatever nature the video is, same as original) then crop or make borders, it is really simple, no rocket science, no elaborated scripts needed, he could leave tiny borders, why would that be stupid to leave it is beyond me. DVD or BD use it. I guess they are stupid. Cropping it and then resizing it which most does if treating videos in that order screws up aspect ratios but no point to discus it again. We tried before.

if he downloaded that file from web, whatever, he does not know how it was messed up, aspect ratio wise etc, no script on Earth would help

[hello_hello]

please, not again

You started it when you referred to my script.

its simple, if op did it himself, he could resize to 16:9 or 4:3 (whatever nature the video is, same as original) then crop or make borders, it is really simple, no rocket science, no elaborated scripts needed, he could leave tiny borders, why would that be stupid to leave it is beyond me. DVD or BD use it. I guess they are stupid.

Once again you're taking an extreme view and missing the middle ground. You referred to people removing tiny black borders at all cost. I think those people are few and far between. I referred to removing tiny borders if I was planning on encoding anyway, in which case it seems silly not to.

DVDs have large borders because they're traditionally viewed with over-scanning enabled so you don't see them. I don't view my encodes with over-scanning enabled so I like nice clean borders.

Cropping it and then resizing it which most does if treating videos in that order screws up aspect ratios but no point to discus it again. We tried before.

It's not hard. Back in the day, video had to be mod16. You couldn't resize to mod16 and then crop, because unless you cropped mod16 it wouldn't be mod16 any more. So you calculated the correct cropping and resizing in advance so you could resize to mod16. The principle is exactly the same whether you want mod16, a bunch of encodes at exactly 16:9, or if you want related encodes to have the same dimensions. Sure it can potentially distort the picture if it's not done correctly, so you do it correctly. Pretty much any GUI will do it for you or there's stand-alone calculators. No elaborate scripts required.

if he downloaded that file from web, whatever, he does not know how it was messed up, aspect ratio wise etc, no script on Earth would help

And if you resize it first and then crop, there's no possibility of resizing incorrectly? Chances are if video is messed up when it's resized it's not because cropping wasn't correctly factored into the equation, it's probably because the wrong equation was used in the first place.

[_Al_]

I'm pretty sure if you go ahead and write another page or two I perhaps start to understand how simple resize to exact aspect ratio and then cropping, keeping exact aspect ratio is somehow a faulty workflow

[hello_hello]

Not a single response to any of the points I made. Instead you're either being dense or just making stuff up. I didn't claim your workflow is somehow faulty, but you can't choose the output resolution if you resize first and then crop whatever black there happens to be. For that you need to calculate the required cropping and resizing together. There's nothing faulty about that workflow either, even if you happen to find it too complicated.

Are you really under the impression cropping doesn't change the aspect ratio????

[_Al_]

For the love of God. Take BD, DVD or VHS capture and resize to 16:9, 4:3 whatever source you have and then crop. You know what to resize (exact 16:9 or 4:3 resolutions, modes are excellent mostly 16, perhaps 8) and then cropping does not change aspect ratio. Do you understand that aspect ratio is not changed if this workflow is followed and even if using cropping? That seams to be your problem. But your workflow (I do not know why sticking with it at all cost) crop, resize, messes it up right away because you do those to a mode. And you need to make calculation. Sometimes nature makes no sense, proper sequence is important. You do not make an error if things work right but in your case mostly they do not.

Your method, or crop first, then resize also as seen all over the web, could be used where it does not matter already, if the source was tampered before. Because you do not know how it was achieved. Paradoxically, your new aspect ratio error might oddly enough positively compensate original aspect ratio error in the first place. Who knows.

That is why to get rid of tiny borders at all cost makes little sense to me. Leaving them you leave space for another tempering without introducing another error AND you keep fine modes as well. See this topic. Someone was cropping to a 702, the heck why. As soon as you say black borders are stupid to leave alone, you broke that godly alignment of fine numbers again. Not talking about pillarbox or letterbox, just black borders.

[davejavu]

As long as you allow the proper resizing and cropping values to leave the final picture the correct shape does it really matter which way around you do it?

Personaly, I normally crop then resize by working out the how much I want to crop, calculating how much of the original height and width I will be left with and then calculating the exact amount of resizing to both vertical and horizontal dimensions I want to apply. I normally keep the height and just resize the width.

_AI_, I have found that if I resize an anamorphic 16/9 DVD containing a 2.35/1 video from 720x576 to 1024x576, exactly 16/9 resolution, and then crop the top and bottom borders the encoder outputs 1024x576 with the video stretched vertically thus distorting the aspect ratio. The calculations to work out the proper 2.35/1 final resolution and then the cropping values are more complicated as you are also resizing the black borders before applying the crop.

[_Al_]

Encoder settings are wrong, try to set to ignore aspect ratio. No aspect ratio should be set if you crop. You have to go with 1:1. Square pixel. Aspect ratio 1.0. whatever it is marked in settings. Remember if you crop for the first time, even after resizing, real proportions are kept.

It is only after you take that encoded cropped video and try to resize using certain mode yet again, you are beginning to loose true proportions. Only leaning to an info or an estimation that that movie is 2.35:1 could lead you and not to messed it up too much, but errors are being introduced anyway, you just not deviating too much. That is what hello_hello is trying to bring up or rather was with heated discussions before. But this is only if video was treated before. Folks do not distinguish between those two. Originals and already encoded videos before (web downloads most likely).

EDIT: I meant cropping after resizing, not cropping after cropping, I fixed that

[hello_hello]

For the love of God. Take BD, DVD or VHS capture and resize to 16:9, 4:3 whatever source you have and then crop. You know what to resize (exact 16:9 or 4:3 resolutions, modes are excellent mostly 16, perhaps 8) and then cropping does not change aspect ratio.

Comedy gold!!
So you're saying, if I resize a PAL DVD to 16:9.... 1024x576 for example.... and I crop 16 pixels from each side so what's left is 992x576, it still has a 16:9 aspect ratio?
Of course it doesn't. I guess your problem is not being able to distinguish between aspect ratio and picture distortion.

But your workflow (I do not know why sticking with it at all cost) crop, resize, messes it up right away because you do those to a mode. And you need to make calculation. Sometimes nature makes no sense, proper sequence is important. You do not make an error if things work right but in your case mostly they do not.

I've explained it over and over again.... you can't achieve a particular resolution/aspect ratio unless you calculate cropping and resizing together.
Take the previous example of resizing to 1024x576 and cropping 16 pixels from each side. It's not 16:9 any more but I want 16:9, so I work it out.
If the DVD has 16 pixels of black after resizing to 1024x576, before resizing it'll probably have around 12 (I'm just guessing for an example), so I take the 720x576 DVD and crop 12 pixels each side for 696x576, then I crop a little top and bottom until it's 16:9 again. For that example it works out to a total of 19 pixels, so I'd crop and resize like this:

Crop(12,8,-12,10)
Spline36Resize(1024,576,0,1,0,0)

That gives me a nice and clean 16:9 image and the aspect error is 0.036%. A fraction of a pixel.
The "mode theory" is nonsense because I can resize the above image to any 16:9 dimensions without distorting it. Achieving a particular mod is no different to achieving a particular resolution. You have to adjust the cropping accordingly to get there without distorting the picture.

That is why to get rid of tiny borders at all cost makes little sense to me. Leaving them you leave space for another tempering without introducing another error AND you keep fine modes as well. See this topic. Someone was cropping to a 702, the heck why. As soon as you say black borders are stupid to leave alone, you broke that godly alignment of fine numbers again. Not talking about pillarbox or letterbox, just black borders.

We don't know the height of the OP's video so it's all guess work, but if I was to re-encode a 720p video with a few fine lines of black down each side I'd crop and resize something like this:

Crop(4,2,-4,-2)
Spline36Resize(1280,720,0,0 ,-1,-1)

The aspect error is virtually zero, the edges are clean and the picture fills a 16:9 display.
If the video isn't already close to 16:9 or 4:3 I'd aim for a particular mod instead. The principle is the same though, and when encoding episodic DVDs it's possible to crop and resize each episode to the same dimensions without distorting the picture.

[hello_hello]

Encoder settings are wrong, try to set to ignore aspect ratio. No aspect ratio should be set if you crop. You have to go with 1:1. Square pixel. Aspect ratio 1.0. whatever it is marked in settings. Remember if you crop for the first time, even after cropping, real proportions are kept.

Errr...... what do you imagine this does?

Crop(14, 6, -12, -26)
Spline36Resize(704,388)

The cropping just crops pixels. It doesn't matter if they're 1:1, any other shape, or if the image is 1.85:1 or 4:3. It can only crop whole pixels. They weren't resized first. The pixel aspect ratio isn't changed by the cropping.

That is what hello_hello is trying to bring up or rather was with heated discussions before. But this is only if video was treated before. Folks do not distinguish between those two. Originals and already encoded videos before (web downloads most likely).

You keep bringing it up as though it's relevant. If someone's messed up the aspect ratio it's messed up, and neither your method or mine will magically fix it or determine the correct aspect ratio.

Small errors are always going to be introduced. Take a video you resized to 16:9 and cropped the black so it's 1264x540 (as an example). Now view it on a 1080p TV. The player isn't going to resize to 1920x820.253. It'll be 1920x820 or 1920x821 because the display only has whole pixels. Any aspect error I introduce when cropping and resizing wouldn't be any greater because I'm fussy about it, although in reality a few pixels either way isn't enough to notice. Chances are the picture was distorted way more than that by the time it made it's way to a DVD or Bluray disc.

[_Al_]

u-n-b-e-l-i-e-v-a-b-l-e

[hello_hello]

What don't you believe? I can only image you don't believe it because you can't understand it. What needs explaining again?

[hello_hello]

I'll try once more while keeping it as simple as I can.

You've already said it's okay to resize a Bluray image to 16:9 dimensions, but let's do the math:

1080 / 1920 x 1280 = 720

So it follows if you cropped 108 pixels from the height to remove borders (1920x972).

972 / 1920 X 1280 = 648.

Can you see how it's possible to resize to 1280x648 after cropping without distorting the picture?

When you use a DVD as the source without ignoring the pixel aspect ratio as you advised...
(PAL 16:9 DVD, 12 pixels from the sides and 6 from the height for 708x570).

570 / 708 / (64/45) x 1280 = 724.6

or

570 / 708 / (64/45) x 720 = 407.6

Not having bionic eyes I doubt I'd see half a pixels worth of distortion after resizing to 1280x724 or 720x408, but I'd probably fiddle with the cropping a little to make it even more accurate if possible.

With the aid of a cropping/resizing calculator, it's not hard to crop and resize pretty accurately, and to emphasise the reason one more time, by doing it that way, if you choose to, you can crop and resize to a predetermined aspect ratio or mod without distorting the picture.

[davejavu]

Encoder settings are wrong, try to set to ignore aspect ratio. No aspect ratio should be set if you crop. You have to go with 1:1. Square pixel. Aspect ratio 1.0. whatever it is marked in settings. Remember if you crop for the first time, even after cropping, real proportions are kept.

The encoder settings aren't wrong, just trying to demonstrate that if I followed your example of resizing to an exact 16/9 aspect ratio and cropping a DVD you get distorted video as a result. You have to resize to the video remaining after cropping to keep the 'real proportions' and I find it easier to calculate the new resolution/cropping values and the results easier to predict if I crop first then resize what is left. If cropping and resizing I always encode as square pixel. I only use aspect ratio settings if I am leaving the black bars in the video and keep original aspect ratio.

Whenever you are cropping the end result is often a non-standard resolution, ie. not exactly to a particular aspect ratio, as the black bars vary in size and proportion from video to video, and sometime in the same video, unless you are prepared to crop away some of the video as well as the black bars. Resizing first then cropping won't magically fix aspect ratio errors just because you do it in that order. You can do it that way but yYou still need to calculate the appropriate values for resolution and cropping, it is just involves a more complicated set of calculations.

[_Al_]

We could talk about 704 vs. 720. If there is 16:9 information within 704 then crop 8,0,-8,0 first to have 16:9 information there, but that's it.

It is not like DVD movie area within 720x576 is anamorphic and rest of the letterbox is not or whatever combination.

If you have distortion either way then how is it possible that while watching DVD disc you see correct proportions? Or are they?

If you see your DVD disc with true , correct proportions, then resizing (from 720 or 704) to 16:9 has to give you same visual as your original DVD. That is what DVD is doing. There is no information about true Aspect ratio of the movie, like 2.35:1 or whatever. DVD player just follows blindly 16:9 or 4:3 flag and puts it on screen. As was said before, some players follow 720, some 704 columns to 16:9 or 4:3. But no other magic is done here. The "weird" anamorphic calculations are done while making DVD, having square pixel and making it anamorphic, adding letterbox.

[hello_hello]

_Al_,
if you resize to 16:9 and then crop, you're still effectively picking a pixel aspect ratio to use for resizing, just as you do if you crop first, only in your case you appear not to be aware of it.

720 x (64/45) = 1024 (1024x576)

or

704 x (16/11) = 1024 (1024x576)

or if you don't crop and use 720 as the starting width

720 x (16/11) = 1048 (1048x576)

What happens if you need to crop 18 pixels from each side instead of 8, but you want a mod16 width after resizing? Increase the cropping on one side by two pixels.

682 x (16/11) = 992 (992x576)

There's nothing special about resizing a 16:9 DVD to exactly 16:9, or cropping 8 pixels from each side first and resizing to 16:9. It's ultimately still done based on those pixel aspect ratio calculations. Cropping top and bottom doesn't change that either.

Have you ever used anamorphic encoding for DVDs? For PAL if you don't resize, one of the above pixel aspect ratios are set by the GUI. If you only crop, the pixel aspect ratio remains the same. 64/45 or 16/11 for 16:9 PAL. It doesn't matter if you crop 80 pixels from each side and 160 top and bottom, or if you only crop 2, using one of those PARs (whichever you choose) you can work out the correct DAR for the remaining video, exactly how a player would do it.

Only resizing changes the pixel aspect ratio. Resizing to square pixels changes the pixel aspect ratio to 1:1, but what if you took a DVD with a 16/11 PAR, cropped 6 pixels and resized back to 720x576? The new DAR must be a tiny bit wider than 16:9 as you only cropped 6 pixels each side instead of 8. It's 59/33 or 1.7878 if you work it out. Therefore a new pixel aspect ratio needs to be set to compensate for the resizing back to 720 so it'll display correctly, and according to MeGUI it'd be 236/165.

720 x (236/165) = 1029.8181
1029.8181 / 576 = 1.7878

In case it's not clear, that's the problem I was having in the original thread where you first told me me to ignore pixel aspect ratios and claimed I should be resizing and then cropping etc.
When you open a 720x576 or 720x480 video, no matter what the format, MeGUI assumes an NTSC or PAL pixel aspect ratio. So if I was re-encoding the above example I'd have to check the PAR (or DAR) myself and tell MeGUI to use 236/165 (or a 59/33 DAR). There was no error when the MKV was created. but in the case of MeGUI you have to tell it to use a 236/165 PAR for the source rather than the generic or ITU PARs, otherwise it will resize incorrectly.

[_Al_]

listen, using these in my scripts if encoding anamorphic MP4 :

set sar=1:1
if %ar%==4:3 if %h%==480 if %w%==720 (set sar=8:9)
if %ar%==4:3 if %h%==576 if %w%==720 (set sar=16:15)
if %ar%==16:9 if %h%==480 if %w%==720 (set sar=32:27)
if %ar%==16:9 if %h%==576 if %w%==720 (set sar=64:45)

if %ar%==4:3 if %h%==480 if %w%==704 (set sar=10:11)
if %ar%==4:3 if %h%==576 if %w%==704 (set sar=12:11)
if %ar%==16:9 if %h%==480 if %w%==704 (set sar=40:33)
if %ar%==16:9 if %h%==576 if %w%==704 (set sar=16:11)

if %ar%==16:9 if %h%==1080 if %w%==1440 (set sar=4:3)

I'm aware of this. Why to bring it up if encoding to square pixel? What for? If talking about anamorphic MP4 from DVD, not resizing, good for later use, nothing is messed up. Lots of folks have their own DVD's from VHS or DVavi and want MP4, so why not to back it up like that with very generous bitrate.

No wonder, there is million threads about this and if looking at it first time everyone messes it up anyway, creating avisynth script, because it is insanity, just lets be simple and tell everyone how it works, what DVD player does. If it does not work like that, DVD is wrong. and then let's fix it - custom crop-what-not-s*** , using coefficients, crop the heck out of it, hey what's movie aspect ratio?, what if original user cropped live image to get shiny 16 mode, then it would not helped much anyway, whatever. But that is another story.

And what happens if I crop 18 pixels or whatever? Nothing, because it is stupid thing to do before resize. Why would I complicate it like that and started using coefficients. what nots, GUI's, calculators, for what? Only those 8,0,-8,0 , if I believe or know, information is within 704x576.

I'm not saying it is special, resize to 16:9 (4:3) , then crop, it is the other way, it is a normal, simple thing to do.

And again lots of bla-bla. Not necessary. Then how MeGUi works or does not.