704x400 versus 704x396: Does it make a difference?

[Starks]

I keep hearing how x264 is kinder to Mod16 or something. What's the deal?

[jfs]

Video that's mod mod16 needs to be padded up to mod16 for the codec to be able to encode it. This padding obviously makes the encoded images larger and creates some possibly harder-to-encode cases in the edge regions where the padding has been applied.
Although the difference from 396 to 400 lines is only 4 lines that need to be added, which doesn't cost much in inefficiency. It's still a better idea to go for mod16 resolutions though, for compatibility reasons. If you want to you can stretch the video into a mod16 frame and set it anamorphic in the container. Ie. encode at 704x400 but sat 16:9 anamorphic in the container, to get 711.11x400 on playback.

[TheFluff]

Originally Posted by Rizon

14:05:17 [Rizon] -!- TheFluff [thefluff@MOD16.is.my.Religion]

Serious business. Don't offend my religion. :|

[Quarkboy]

By far the greatest concern you should have is not blaspheming TheFluff's religious beliefs. Unless you follow his teachings exactly, you should expect a hugely long winded and point-by-point reply explaining exactly why you have just offended his God, and how you might repent for your sins. To avoid this, either don't ask this oft' asked quandry, or just do what he says.

Other than that, it's something that only encoders would really care about.

[TheFluff]

Originally Posted by Quarkboy

By far the greatest concern you should have is not blaspheming TheFluff's religious beliefs. Unless you follow his teachings exactly, you should expect a hugely long winded and point-by-point reply explaining exactly why you have just offended his God, and how you might repent for your sins. To avoid this, either don't ask this oft' asked quandry, or just do what he says.

You know what Quarkboy? I like you. :V
I wish I could write burns like that one.

[Starks]

Originally Posted by jfs

Video that's mod mod16 needs to be padded up to mod16 for the codec to be able to encode it. This padding obviously makes the encoded images larger and creates some possibly harder-to-encode cases in the edge regions where the padding has been applied.
Although the difference from 396 to 400 lines is only 4 lines that need to be added, which doesn't cost much in inefficiency. It's still a better idea to go for mod16 resolutions though, for compatibility reasons. If you want to you can stretch the video into a mod16 frame and set it anamorphic in the container. Ie. encode at 704x400 but sat 16:9 anamorphic in the container, to get 711.11x400 on playback.

That's all fine and dandy, but someone explain Mod16 to me in layman's terms?

[Sylf]

"Mod 16" literally means divisible by 16. It has something to do with these codecs liking to handle the video in blocks - like 16x16 pixels.

[Quarkboy]

Originally Posted by Starks

That's all fine and dandy, but someone explain Mod16 to me in layman's terms?

if X mod 16 = 0, then X is "mod 16".

To put it another way, x needs to be divisible by 16. 704 is divisible by 16. 400 is divisible by 16, but 396 is not.

Why 704x396, then? because 704/396 = 16/9, i.e. the aspect ratio is exact. 704/400= not exactly 16/9 (off by a percent or so), and therefore there is a tiny bit of distortion.


To answer WHY mod 16 is so important requires that you understand a little bit about how all mpeg based compression works. The primary "element" in such a compression is a macroblock, sized 16x16 pixels. The original video is divided into these logical blocks as part of the compression algorithm. If the video isn't divisble by 16 both horizontally and vertically, then some of these blocks need to be "padded" with fake data for the compression scheme to work. This wastes bits depending on the implementation of the encoder.
Also, technically it is not even in the specifications of the format to have a resolution that is not mod 16, so hardware playback of such encodes might be borked (although, in practice, most divx DVD players have no trouble playing them back).

The amount of wasted bits is not noticable to the vast majority of the viewers. The amount of aspect ratio distortion is also not noticable to the vast majority of the viewers. The solution where you specify an aspect ratio in the container like mkv and the player dynamically fixes the aspect ratio is also not noticable to the viewer.

That's pretty much all there is to say on the subject.

[Starks]

But why didn't it make a difference with Xvid (which I hear prefers Mod4)?

[Nicholi]

Originally Posted by Quarkboy

Why 704x396, then? because 704/396 = 16/9, i.e. the aspect ratio is exact. 704/400= not exactly 16/9 (off by a percent or so), and therefore there is a tiny bit of distortion.

Well, you do not need a final resolution that is exactly 16:9 to be accurate. This is only true if you blatantly resize 704x396->704x400, you have introduced a very small AR error. However encoding to a resolution that is is not exactly 16:9 does not necessarily mean you have introduced an error. That is entirely the wrong way to think about it. You can encode to literally any final resolution you want and have zero AR error. But hao?! Siiimmple. Using crop before you resize you can manipulate the AR error to be as low or as high (wtf^m) as you want. This is because you are in essence taking into account how much the pixels will be stretched/squished and cutting off just enough so that the final picture will look identical to the original in terms of aspect. I.E. a circle stays a circle and a square stays a square. So simply using 704x400 does not mean you are "off" by anything. If you are resizing without cropping you are introducing a small AR error, though 396->400 is so insignificant you can ignore it (its almost exactly 1%) unless you really want to make the AR error 0.

Mostly the above is only relevant to DVD encodes because you actually have some semblance of control over the source. Unlike with jpn caps in which you are just stuck with what you got.

Originally Posted by Starks

But why didn't it make a difference with Xvid (which I hear prefers Mod4)?

Just wondering, where do you "hear" such things?

[Harukalover]

Originally Posted by Starks

But why didn't it make a difference with Xvid (which I hear prefers Mod4)?

Actually that's the fault of people thinking they need to actually care about mod16 and container support only when it involves H.264.

Poor XviD has been abused for years and very few seem to be looking into changing this abusive behavior.

[Starks]

Originally Posted by Harukalover

Actually that's the fault of people thinking they need to actually care about mod16 and container support only when it involves H.264.

Poor XviD has been abused for years and very few seem to be looking into changing this abusive behavior.

So, Xvid benefits from Mod16 resolutions as well?

[Zero1]

Yes, all current and past MPEG specs benefit from mod 16, because they all make use of 16x16 macroblocks (and H.264 also has smaller blocks, but mod16 is derived from the largest block size).

I posted about this some time ago, and even still images benefit from this idea, but since they do not use macroblocks, mod8 is fine (it's to do with DCT).
http://forums.animesuki.com/showpost...7&postcount=11

Originally Posted by Zero1

Also while I'm here, I thought I'd show you the power of mod8/mod16 (mod16 doesn't apply for still images like JPEG, but mod8 still applies due to DCT). The first image is 640x352 and is 155KB, the second is 640x351 and is 155.4KB. Same image just one line shorter, but the filesize is larger.

Also, although thankfully most of us never do interlaced encoding, I should drop in that interlaced encodes should be mod32.

Also what Nicholi was trying to get at was the image aspect ratio and frame size/aspect ratio. Providing you resize the image correctly, it doesn't matter how much you crop after, because it does not affect the aspect ratio of the image, just the aspect ratio of the frame. For example, resizing from 720x480 to 640x360 and cropping to 640x352 is fine, resizing from 720x480 to 640x352 introduces AR error.

[checkers]

interlaced encodes should be mod32 vertically, they can still be mod16 horizontally, correct?

[Zero1]

Yeah, mod32 basically comes from having two fields at mod16; the width is obviously not affected by interlacing, so it can still be mod 16. If you had an interlaced encode that was mod16; it means that each field is now mod8, so for instance 704x400 is not a good resolution for interlaced encodes because each field has 200 lines of resolution, which is obviously not mod16; and suboptimal.

Either way you look at it, it still boils down to mod16; either mod16 frames, or mod16 fields (but since there are two fields, it becomes mod32 overall).

[SeijiSensei]

Thanks to all of you for the clear explanation of this issue. I'd been wondering for a while why some encodes were at 704x400 despite that not being 16:9.

[SirCanealot]

Originally Posted by TheFluff

Serious business. Don't offend my religion. :|

TheFluff, I see the light! How can I join you in your mighty and untiring campaign?

[Unearthly]

I'd been wondering for a while why some encodes were at 704x400 despite that not being 16:9.

Yeah, it's probably just because they are too lazy/ignorant to mux the 16:9 AR flag. You can change it during playback though, so it's not the biggest issue.

[martino]

I wouldn't say it's laziness or ignorance. Take a look at the AR error. It's really small, and I would say not worth to bother over it and have the decoder resize the output. And as you said, you can set it yourself when playing back, so there really isn't a problem if you feel like you really need that 16/9 AR...

[Unearthly]

I wouldn't say it's laziness or ignorance. Take a look at the AR error. It's really small, and I would say not worth to bother over it and have the decoder resize the output.

Well, it IS still an error and it takes probably less than 30 seconds to add the parameter. It might be easy to justify, but I I'd sooner say 'Why not' than 'Why'? I don't believe there is any reason to not include the parameter unless you don't want to spend the time to do it (a whole 30 seconds compared to how many hours it takes to make a fansub?) or you are unaware of it.