Handbrake - What does Modulus mean?

[hello_hello]

Mod4 is fine. For years I've used resolutions such as 704x396 or 960x540 or even 640x360 when resizing standard definition video because they're all exactly 16:9 dimensions. They're all also mod4. Number of playback problems to date..... none.

I don't think using anamorphic encoding is necessarily a bad idea. For example... you're encoding a video that's exactly 16:9. You decide to resize to 720x400 so the mod16 police won't murder you in your sleep, but it's not 16:9 or 1.7777777:1, it's 1.8:1. So, courtesy of anamorphic encoding you can encode at 720x400 while specifying a 16:9 aspect ratio (Handbrake would do it for you), and as long as your player supports anamorphic MKVs or MP4s, it'll display correctly. If the player doesn't support anamorphic video it'll display it with a 1.8:1 aspect ratio, which is hardly the end of the world.

When using anamorphic loose you can't choose the height but when you set a width Handbrake should adjust the height by the same percentage, or as close to the same as it can. If you're resizing a 16:9 video to a width of 720 the height that gives you the closest dimensions to 16:9 would be 404, but if you've specified a modulus of 16 it can't use 404 so it should resize to the closest mod16 height, which would be 400. That's just an illustration of how it "should" work, but I've not used Handbrake's anamorphic encoding myself.

I'd describe the above as resizing to square pixels and using the anamorphic option to fix any aspect error. It "should" work for sources with square pixels but not for anamorphic sources such as DVDs because you can't choose the height yourself..... you could use "anamorphic custom" instead and take over running the show, but "anamorphic custom" is Handbrake's "let the user make a complete mess of everything" anamorphic option so you do need to know what you're doing.

[hello_hello]

Having done further testing with the resizing calculator you linked me to earlier in this thread, I now understand more what you talked about when you said aspect error. Currently, trying to encode a movie, with the mod set to 8, Handbrake tells me the resolution of the output file will be 1280x536. Inputting that in the resize calculator tells me it has an aspect error of approx. -35.33%. That doesn't sound good.

It does sound like that's because you're not entering the cropping Handbrake is using.

In the top right corner of the resize calculator, I can see the Crop options. I tried inputting a few numbers in the boxes just to see what would happen, but I am not sure how to make it adjust the aspect error, because as soon as I press Enter on the keyboard, it puts 0 back in the crop field. What am I doing wrong?

It can be a bit fiddly to enter large cropping amounts as you can only see two digits worth of cropping, so cropping 100 pixels looks like cropping 10 and cropping 102 pixels looks like cropping 10, as does cropping 104 pixels..... it's an unfortunate design flaw and can result in accidentally entering large cropping values that send the calculator into a tizzy.

It displays the resolution after cropping just below the cropping area though. For example if the source width is 1920 and you crop 104 pixels from the left, it should display 1816x1080 under the cropping area. If it doesn't display a sensible resolution, try using the up down cropping arrows instead of hitting enter on the keyboard, and if that doesn't help, try restarting it.

I'm so used to working around the 2 digit cropping display I'd kind of forgotten about it, although I don't use the Yoda calculator much any more as MeGUI's script creator has a similar one built-in these days.

[Hmmm]

A confusing user interface at Handbrake. Right above the actual source fields, it states 1920x1080. I just assumed that was the source and checked the resize calculator. Then I was reminded that it's a movie, it doesn't actually display 1080 pixels in height. So I checked the "Keep Aspect Ratio" box and the actual source field displays 1920x800. That's more like it! Maybe that will solve the problem. I will check.

[Hmmm]

Mod 4, Anamorphic None, Keep Aspect Ratio, and 1280 entered into the Width field, Handbrake displays 532 pixels in height. The resize calculator states an aspect error of -0.25%. Hahaha big improvement! Is that close enough to be acceptable for encoding or should I do something here?

[hello_hello]

Sounds good. I'm OCD when it comes to resizing though, so based on the assumption you're cropping 140 pixels from both the top and bottom, and nothing from the sides, I'd nudge the bottom cropping up to 142 which will drop the aspect error to zero. If you do that, you'll need to take Handbrake's cropping out of auto mode so you can adjust it to match. Not that you'll be able to see 0.25% of aspect error, so it's up to you.

[hello_hello]

Have you tried Vidcoder? It's an alternative GUI for Handbrake, which means it tends to be very much like Handbrake with some extra cleverness added here and there, and I kind of remember it provides a bit more resolution information than Handbrake as you crop and resize. It might even calculate aspect error. I can't remember. It's been a while since I've used it.

It does have one advantage over Handbrake, as. Handbrake won't let you increase the resolution, so for a 16:9 NTSC DVD the maximum width is 720, therefore for square pixel resizing the height must be reduced to give you the correct aspect ratio.
Vidcoder defaults to doing it the other way. The height stays at 480 and the width is increased to around 852. You don't gain picture detail by resizing "up" but you don't lose picture detail through reducing the height, and for PAL that can be quite a reduction. There's more video to encode which means larger file sizes for a particular quality, but you don't lose picture detail.

If you're using anamorphic encoding none of that matters, but when resizing 16:9 DVDs to square pixel dimensions, "up" is the way to do it.

[jagabo]

All resizing introduces artifacts. Avoid resizing when possible and only crop. Use mod4 frame sizes and square pixels for square pixel sources.

For anamorphic sources (DVD) crop mod4 and use anamorphic encoding. The exception is when you have devices that don't obey SAR/DAR flags. In that case you have to resize to square pixels.

[Hmmm]

OK, I should have asked this a long time ago, but I will ask now instead.
How does "resize" differ from "crop"? I've seen you use both terms, but I thought they were interchangeable, but judging by your latest comment, they aren't.

Second question: In the calculator, I wanted to see the aspect error reach 0 by adding 142 in bottom crop, but it's not working the way I thought it would and I think I am using it wrong again, but this time, I am unable to figure out why. I wrote the source resolution as 1920x800. Further down, I selected Mod 4 and entered my own encoding resolution of 1280x532. As mentioned earlier, it states an aspect error of -0.25%. In the top right corner, where the Crop settings are, they are all set as 0, not 140. Right below the crop settings it says the text 1920x800. I thought it was supposed to show my own resolution there? Where do I make the 142 bottom crop adjustment so that it states 0 in aspect error?

P.S. I am downloading Vidcoder now and will check its user interface and settings now to see what it looks like.

[jagabo]

How does "resize" differ from "crop"?

Cropping is simply cutting away a portion of the frame. Resizing resamples the image to generate a different size image.

For example a 2.35:1 movie on a 1920x1080 Blu-ray disc will occupy about 1920x816 pixels of the frame, the rest being black letterbox bars. Cropping would simply remove those black borders leaving a 1920x816 frame. The original image pixels are unchanged and there is no quality lost -- just like cutting away part of a piece of graph paper leaves the remaining blocks unchanged.

Downscaling the entire 1920x1080 frame to 1280x720 is resizing -- the entire original image, including the black borders, has been resized. Or a crop to 1920x816, then downscaling to 1280x544 involves resizing. Resizing results in a loss of quality, even before you start encoding (which will result in more loss of quality).

[_Al_]

Another look at that, sometimes you need crop and resize as well,

You can combine both, if resizing is planned anyway, for example you need to resize 1920x1080 video that is letterboxed (black bars on the top and bottom, like on Blu-Ray disc), you plan to resize to 1280x720 but you want to get rid of those black bars as well.

Spline36Resize(1280,720)  #resizing to horizontal resolution you want
Crop(0,94,1280,532)  # if using mode 4 to crop black bars

so you get 1280x532 at the end, note if you intend to use mode 8, you'd need to cut couple of lines more, to 528 > crop(0,96,1280,528) ...

you can crop first and then resize to do exactly the same, but this order makes it tricky and more calculation is needed, difficult to program it this way if keeping this order or program needs to trust aspect ratio information, in this case 2.4:1 :

Crop(0,140,1920,800)    #getting rid of black bars first for 2.4:1 movie, 1920/2.4=800
Spline36Resize(1280,532)     #again mode4 resizing

but notice first method (resize then crop) does not resize with possible tiny aspect ratio error (depending on mode), it just cuts off lines of video to get particular mode. Also 800/532 is not whole number, mathematically not a decent number at all , just weird fraction . 1280/720 is way more decent ...

Your video already is 1920x800 perhaps so you just resize to 1280 x ?, depending on your mode, but you can resize AND crop just couple of lines to get your desired mode as well ... if using Avisynth or other tools, using Handbrake, not sure, you gotta just resize to final resolution I guess. But this was for me a good reason to explain both resize and crop.

[hello_hello]

All resizing introduces artifacts. Avoid resizing when possible and only crop.

My theory is a DVDs are invariably going to be resized on playback, very likely upscaled to 1080p, sometimes to 4k, so in the over-all scheme of things....
DVD quality isn't anything to get excited about anyway and in my case the TV in the living room has an aspect ratio ignorant media player so I resize to square pixels. I think of it as giving the resizing a head-start.

Seriously though..... I've compared anamorphic DVD encodes to resized DVD encodes and the DVD video itself, and if I resize a 16:9 PAL DVD to 1024x576 (although 960x540 usually works just as well) I think it looks better than an anamorphic encode when running full screen, and mostly looks better than the original DVD itself.

Two screenshots of DVD encodes running fullscreen on my TV. Same MPC-HC bilinear upscaling, no filtering during encoding, same encoder settings..... the only difference is spline36 resized the second one to 1024x576 when it was encoded. Am I wrong to prefer it? Actually, if I am don't tell me. I think I'd prefer to continue enjoying my own ignorance....

[hello_hello]

Second question: In the calculator, I wanted to see the aspect error reach 0 by adding 142 in bottom crop, but it's not working the way I thought it would and I think I am using it wrong again, but this time, I am unable to figure out why. I wrote the source resolution as 1920x800. Further down, I selected Mod 4 and entered my own encoding resolution of 1280x532. As mentioned earlier, it states an aspect error of -0.25%. In the top right corner, where the Crop settings are, they are all set as 0, not 140. Right below the crop settings it says the text 1920x800. I thought it was supposed to show my own resolution there? Where do I make the 142 bottom crop adjustment so that it states 0 in aspect error?

If you're going to apply cropping in the calculator you need to input the original video resolution before cropping. ie 1920x1080. Sorry, I assumed that's what you would be doing. Most Bluray video is 1920x1080 with black bars encoded top and bottom. The cropping removes the black bars and leaves just the picture. Often you're left with 1920x800 as it's a fairly common aspect ratio for movies but the picture itself could have any aspect ratio, and black bars are added as required for a total aspect ratio of 16:9 and a 1920x1080 resolution.
You can specify a source of 1920x800 but you can't also add 140 pixels worth of cropping top and bottom, because you already took that cropping into account when you specified a source resolution of 1920x800.

So.... a source of 1920x1080 with 140 pixels cropped from the top and 140 from the bottom should resize the same way as a 1920x800 source with only 2 pixels cropped from the bottom.

By the way, I assumed Handbrake is cropping 140 pixels top and bottom because that gives you 1920x800, but is that what it's doing? It wouldn't be unusual for it to also crop a little from the sides. It tells you how much it's cropping.

[_Al_]

hello_hello
if anything you loose room on your hardisk, also as soon we start to talk about camcorder videos (not the case here), it is better to do not upscale as oppose talking about movies

another look at it, for 1024x576 you need more bitrate comparing to 720x576 (plus aspect ratio) so technically you loose quality if comparing SAME bitrate, , but anyway it is a free choice, one want square pixels, other does not etc., ...

[Hmmm]

If you're going to apply cropping in the calculator you need to input the original video resolution before cropping. ie 1920x1080. Sorry, I assumed that's what you would be doing. Most Bluray video is 1920x1080 with black bars encoded top and bottom. The cropping removes the black bars and leaves just the picture. Often you're left with 1920x800 as it's a fairly common aspect ratio for movies but the picture itself could have any aspect ratio, and black bars are added as required for a total aspect ratio of 16:9 and a 1920x1080 resolution.
You can specify a source of 1920x800 but you can't also add 140 pixels worth of cropping top and bottom, because you already took that cropping into account when you specified a source resolution of 1920x800.

So.... a source of 1920x1080 with 140 pixels cropped from the top and 140 from the bottom should resize the same way as a 1920x800 source with only 2 pixels cropped from the bottom.

By the way, I assumed Handbrake is cropping 140 pixels top and bottom because that gives you 1920x800, but is that what it's doing? It wouldn't be unusual for it to also crop a little from the sides. It tells you how much it's cropping.

Oh, of course! Silly me!

I didn't notice it earlier, but you are correct, HandBrake does state how much it's cropping in auto-mode, which in this case is 140 top/bottom, and 0 left/right.

Going back to the calculator and correctly filling it out, that means 1920x1080 source with 140 crop on top/bottom gives 1920x800, and my own specified encode resolution of 1280x532 gives an aspect error of -0.25%. Adjusting only the bottom crop to 142 (leaving the top crop still at 140), it now gives me a 0% aspect error That is preferable! And this is all with mod 4, which I have now decided to use.

That (finally) sounds correct to me! Does it sound accurate and correct for you too?
I will manually edit the HandBrake cropping and then start the encode, and hopefully it will give me an awesome file! I can't wait to see if it ends up being good or not hahaha!

Thank you so much to you and everybody else for being so patient with me and helping me through this! I really appreciate it!
Now let's hope this works or else I will have to get back to this thread for more help hahaha

[_Al_]

Adjusting only the bottom crop to 142 (leaving the top crop still at 140), it now gives me a 0% aspect error That is preferable! And this is all with mod 4, which I have now decided to use.

1080-142-142=796, so you get 1920x796, then you resize to 1280x532 that is not same ratio, you get a tine aspect ratio error,

To not get aspect ratio error at all, you need to resize first to same aspect ratio like 1920x800 and then crop it. 1920/800=2.4 , then 1280/2.4=533.333 so to not change aspect ratio at all you'd need to resize to that, and that is impossible. One has to crop first and then resize to get exact 2.4:1 again without any error. That could be tricky to do it. I mentioned before 1920x1080 resize to 1280x720 case, where it was ok.

Those 1920x1080, 1280x720 are magic numbers in our quest for 0% error with 16/9 AR, they are cool together mathematically. As soon as you deal with 2.4:1 AR, 24/10, you are doomed, always getting tiny error resizing if wanting 1280 at the end.

So in your case to get 0% aspect ratio error, you'd need to add black bars to video to get 1920x1080, resize it to 1280x720 and then crop it again to your desired mode, like 4, then 1280x532. Cropping does not change aspect ratio. If you want to resize it again with 0% error, then again fill it to 1280x720, resize it to a 16/9 dimension and crop it again.

Does anyone can come up with another method?


This is highly academic discussion, no-one is expecting to follow this workflow, those errors are tiny. Handbrake perhaps cannot do stuff like that, Avisynth+encoder can. Do not think of it as a subject to think about. Just pointing at your 0% Aspect ratio error comment

[Hmmm]

Hmm...
Wait, hold on... Just to ask so I can get some feedback:

Why am I even trying to achieve the perfect resolution for movies? If anything, won't keeping the encode resolution at 1280x720 at all times for both movies and TV give me the perfect picture in both scenarios, PC and TV? Granted, watching it in windowed mode on my PC would give me black bars on the top and bottom, but that isn't really a problem to me as long as the picture is perfect. I watch content in full-screen mode most of the time anyway.

Is this a terrible idea, or am I asking a legitimately decent question given how much complication the unique resolution of movies has caused for me in this thread?

[jagabo]

Why am I even trying to achieve the perfect resolution for movies? If anything, won't keeping the encode resolution at 1280x720 at all times for both movies and TV give me the perfect picture in both scenarios, PC and TV?

What if you get a 21:9 TV or monitor in the future? The player doesn't know the top and bottom parts of the frame are black borders. It will upsize the video until the the top and bottom of the frame touch the top and bottom of the screen. And then add pillarbox bars to fill out the width. You'll have a little picture in the middle of a bunch of big black borders.

If you had cropped away the black borders the picture would fill the height of the screen and only have black pillarbox bars.

[Hmmm]

Hahaha oh. That doesn't sound good.
Out of curiosity, is 21:9 a format that is rising in popularity? Does it have a specific purpose? Is it like 4K Ultra HD, where it is almost guaranteed that all TVs will be in that standard eventually?

[_Al_]

It s just wider, that's all. Wider suppose to be better. But that is all relative. Resolution of TV and size, viewing distance is important also. Why would you care having black bars on TV if TV is big enough with plenty of resolution. Imagine watching 4:3 format on 21:9 TV. There is no such a thing as TV dimension ratio standard. Just proper, like nowadays 16:9 is the way to go. There will be just variety of products and plenty of marketing explaining you that you need to have it. Telling you that black is white, you know the usual ...

[jagabo]

All resizing introduces artifacts. Avoid resizing when possible and only crop.

My theory is a DVDs are invariably going to be resized on playback, very likely upscaled to 1080p... so I resize to square pixels. I think of it as giving the resizing a head-start.

I see that as all the more reason not to resize before encoding. One resize is better than two.

Seriously though..... I've compared anamorphic DVD encodes to resized DVD encodes and the DVD video itself, and if I resize a 16:9 PAL DVD to 1024x576 (although 960x540 usually works just as well) I think it looks better than an anamorphic encode when running full screen, and mostly looks better than the original DVD itself.

That's because you used a sharper resize algorithm in your square pixel encoding. So you've handicapped the player's scaling. And actually, if you look closely at your square pixel encoding you'll see it has introduced oversharpening halos. They are mild but what if your player had used a sharper upscaler? The halos would get worse. And there are some cases where the intermediate resize, regardless of what filter you use, will show obvious moire artifacts. Try the same comparison with this image:



That's a degenerate case, of course. But you sometimes see elements that look like that in videos. Vertical blinds in the background, lines on the side of a skyscraper, striped pants on an actor, etc.

[Hmmm]

1080-142-142=796, so you get 1920x796, then you resize to 1280x532 that is not same ratio, you get a tine aspect ratio error,

To not get aspect ratio error at all, you need to resize first to same aspect ratio like 1920x800 and then crop it. 1920/800=2.4 , then 1280/2.4=533.333 so to not change aspect ratio at all you'd need to resize to that, and that is impossible. One has to crop first and then resize to get exact 2.4:1 again without any error. That could be tricky to do it. I mentioned before 1920x1080 resize to 1280x720 case, where it was ok.

Those 1920x1080, 1280x720 are magic numbers in our quest for 0% error with 16/9 AR, they are cool together mathematically. As soon as you deal with 2.4:1 AR, 24/10, you are doomed, always getting tiny error resizing if wanting 1280 at the end.

So in your case to get 0% aspect ratio error, you'd need to add black bars to video to get 1920x1080, resize it to 1280x720 and then crop it again to your desired mode, like 4, then 1280x532. Cropping does not change aspect ratio. If you want to resize it again with 0% error, then again fill it to 1280x720, resize it to a 16/9 dimension and crop it again.

But... but... the encode finished, and it looks great! I didn't get any aspect ratio error when I did the calculations before I started the encode. And that was with the bottom crop at 142 rather than 140 to fix that tiny -0.25% aspect ratio error I was experiencing before. My resolution for the encoded file is 1280x532, with an aspect ratio of 2.40:1. Isn't the file I have now what I want? It's an awesome encode with excellent quality, great resolution and everything seems to work perfectly (so far)! :P

[_Al_]

My resolution for the encoded file is 1280x532, with an aspect ratio of 2.40:1

Oh yes! Your resolution is 1920x798 to 1280x532, then that's 0% error!

Sorry did not noticed that bottom top difference.

Don't mind me I think in algorithm sense, to do something that algorithm can do for different vertical resolutions. Your case is humanly simplest solution, figuring out what you got.

[hello_hello]

That's because you used a sharper resize algorithm in your square pixel encoding. So you've handicapped the player's scaling.

I don't quite follow the "handicapped the player's scaling" comment.

And actually, if you look closely at your square pixel encoding you'll see it has introduced oversharpening halos. They are mild but what if your player had used a sharper upscaler? The halos would get worse.

I'll have a look but I'm not sure there was a lot of halo creating going on. I think the resizing sharpened the existing halos, or made them more noticeable, however you might describe it.

Here's another way to look at it.....
Most of us have applied noise filtering at some stage despite the fact it blurs to some degree, and we've all de-interlaced even though there's no perfect way to do it. Is there a video filter that only has a positive effect? No adverse effects at all? So assuming resizing is just like any other filtering in that respect.....
Obviously you can look at the screenshot and find some adverse effects, but that aside, which picture do you prefer?

I'm not sure your image is a good example in this case, as it's not anamorphic, so it wouldn't compare apple resizing with apple resizing. I'll confess I often throw caution to the wind and resize the height to some degree, but that's something else again. Do you have an anamorphic picture I can un-squish to see what it'll look like?

There's definitely been one occasion where after encoding I thought "well, that's not good" but it wasn't all my fault. Someone else decided to sharpen the "Analyse That" picture for the PAL DVD a little too much and it snowballed from there. I gave the encoded video to my sister to watch, which she did using her Samsung Bluray player, which upscales just a little too sharply for my taste, and when I walked into her room while she was in the middle of watching it my immediate thought was "I guess I'll be doing that one again".

For me though, stretching the width results in more happy than sad 99% of the time, otherwise I'd find a way to avoid it.

[hello_hello]

hello_hello
if anything you loose room on your hardisk, also as soon we start to talk about camcorder videos (not the case here), it is better to do not upscale as oppose talking about movies

another look at it, for 1024x576 you need more bitrate comparing to 720x576 (plus aspect ratio) so technically you loose quality if comparing SAME bitrate, , but anyway it is a free choice, one want square pixels, other does not etc., ...

It kind of wasn't my choice originally. I used anamorphic encoding until the aspect ratio ignorant media players came to stay. There's two TVs here with built-in media players and a Bluray player that ignores MKV/MP4 aspect ratios, and I was a bit pissed about it initially. I already had a far collection of anamorphic encodes, and my personal media player is a PC, but I did some anamorphic vs square pixel comparison encoding to see how much worse it'd look only to be pleasantly surprised.

I generally use CRF18 for DVD encodes, so yes resizing them up increases the bitrate and requires more hard drive space, but it's all relative. Somewhere between copying the original video to a hard drive and declaring re-encoding to be the work of the devil, and re-encoding it to burn the output as a video CD, we've all found our own little comfort zone. At the moment, mine prefers square pixels.

[jagabo]

I'm not sure your image is a good example in this case, as it's not anamorphic

It's just a 720x576 image. It's anamorphic if I say it's anamorphic. It's anamorphic if you treat it as anamorphic. You can treat it exactly the same way you treat a 16:9 DAR MPEG 2 video.

[hello_hello]

I gave it to Irfanview to upscale as a quick test. Lanzcos resizing.

Resized directly from 720x576 to 1920x1080



Resized in two steps. 720x576 to 1024x576, then 1024x576 to 1920x1080



Edit: I meant to include this one with the other two but got distracted. It's a PAL resizing I tend to use a fair bit.
720x576 to 960x540, then 960x540 to 1920x1080



The result was pretty much as I thought it'd be. Too be honest, maybe not as bad as I expected, but obviously messing with the height isn't ideal. Mind you thinking about it, most video that finds it's way to DVD these days would start off at a higher resolution, downscaled and anamorphically squished, possibly sharpened, maybe edge enhanced, encoded with a less than ideal bitrate.... what's the odds of fine detail surviving the process so I can mess it up?

[poisondeathray]

It kind of wasn't my choice originally. I used anamorphic encoding until the aspect ratio ignorant media players came to stay. There's two TVs here with built-in media players and a Bluray player that ignores MKV/MP4 aspect ratios, and I was a bit pissed about it initially.

Did you explore different methods of signalling ? Container flags, vs stream SAR ?

[Hmmm]

My resolution for the encoded file is 1280x532, with an aspect ratio of 2.40:1

Oh yes! Your resolution is 1920x798 to 1280x532, then that's 0% error!

Sorry did not noticed that bottom top difference.

Don't mind me I think in algorithm sense, to do something that algorithm can do for different vertical resolutions. Your case is humanly simplest solution, figuring out what you got.

Haha it's okay. Thanks for the answer. I'm so happy with the output file, it's exactly what I wanted!

Now here starts the project of encoding everything in my collection! Now I know how to encode it correctly, so it will hopefully go without any problems!

[Hmmm]

One more question.

I suddenly saw the option "Deinterlace" in the Filters section of Handbrake. All through my life, I've hard that deinterlacing is good and should be On. I have it on Off :/
Should I use deinterlacing, and if so, are there any recommendations to speed ("custom, fast, slow, slower, bob")?

[Hmmm]

Having researched and read a few pages about interlacing, it appears that deinterlacing should only be used on material that is interlaced and can damage picture quality when it is already progressive. In that case, I'll have to figure out if my Blu-ray Discs are interlaced or progressive. I hope BDInfo can help with figuring that out.