PDA

View Full Version : x264 and mod16 resolutions


simps
28th September 2010, 06:49
I remember when x264 would give us a warning about non-mod16 resolutions.

So, should I care to adapt my sources to mod16 resolution before encoding with x264 if my aim if maximum possible quality? Will that make a difference at all with recent x264?

Daiz
28th September 2010, 07:45
It's true that you might get some tiny bit of extra compression efficiency using a mod16 resolution, but the difference in x264 today is so small that it doesn't really matter in practice. The warning was removed for a reason.

creamyhorror
28th September 2010, 09:13
Don't resize if you don't need to. It can hurt quality (not by much, but still).

J_Darnley
28th September 2010, 13:55
That warning was removed for a good reason, to stop scaring people about it.

LoRd_MuldeR
28th September 2010, 19:01
Don't resize if you don't need to. It can hurt quality (not by much, but still).

I'd rather crop it down to the next mod16 resolution than resizing the video. Resizing will effect all pixels, while with cropping you loose 15 lines/columns at most.

Anyway, as others said before, don't worry too much about encoding at non-mod16 resolutions...

mandarinka
28th September 2010, 21:08
I'd rather crop it down to the next mod16 resolution (...)

Please don't suggest such things to people :)

LoRd_MuldeR
28th September 2010, 21:09
Please don't suggest such things to people :)

Don't suggest what, please ???

AlekseiV
29th September 2010, 08:20
Is the difference negligible as long as the input is valid YV12? (mod4 width mod2 height, I think)

Like, a video that is only mod2 is essentially the same as a mod4 is essentially the same as a mod8?

kypec
29th September 2010, 08:35
Please don't suggest such things to people :)
LM is not suggesting anything to him/her. He said he would rather crop which expresses his (=LM's) personal opinion on the matter of cropping/resizing - and I'm gonna second that: "I (=kypec) would rather crop +/-15 pixels off the source frame, especially when dealing with FullHD resolutions where anything<8 pixels missing at top/bottom of the picture is negligible to my watching experience." :)

nurbs
29th September 2010, 08:52
Like, a video that is only mod2 is essentially the same as a mod4 is essentially the same as a mod8?
It's about how many pixels you need to pad to the next higher mod16 resolution. If there is only two lines missing the compression loss is less than if you need another 14 to pad it. The loss isn't very high though and it's always better to crop than to leave black bars.

mandarinka
29th September 2010, 12:02
Is the difference negligible as long as the input is valid YV12? (mod4 width mod2 height, I think)

Mod2 (non-mod4) width YV12 is also valid. It is just avisynth's vfw interface that refuses to work with such resolution.

Sharktooth
29th September 2010, 12:40
id rather use mod 16 too. that's coz some avs filters wont work with non mod 16 resolutions.

mariush
29th September 2010, 14:06
I remember when x264 would give us a warning about non-mod16 resolutions.

So, should I care to adapt my sources to mod16 resolution before encoding with x264 if my aim if maximum possible quality? Will that make a difference at all with recent x264?


Short answer, to the topic, is NO, you should not care.

x264 prefers to have width and height multiples of 16, but if you don't give him width or heights multiple of 16, it will automatically "clone" the last line or column until the width or height is multiple of 16. Then, it tells the player to crop the image to the normal width and height.

(well, at least for height, I'm not 100% sure about width)

This already happens for 1920x1080 videos - I'm pretty sure x264 automatically adds 8 lines at the bottom, because 1088 is multiple of 16

The effect on compression and quality of adding these lines to the video compared to cropping down the frames to multiples of 16 is so small it doesn't matter.


As it was said above, the only place where you would be interested in having images multiple of 16 is when applying some filters on the video and these filters require widths and heights of 16.

mandarinka
29th September 2010, 15:45
id rather use mod 16 too. that's coz some avs filters wont work with non mod 16 resolutions.

You can crop at the end of the script.

LoRd_MuldeR
29th September 2010, 19:54
It's about how many pixels you need to pad to the next higher mod16 resolution. If there is only two lines missing the compression loss is less than if you need another 14 to pad it. The loss isn't very high though and it's always better to crop than to leave black bars.

I agree. I'd always crop away the "black bars", even if that would result in a non-mod16 resolution! The "black" area itself doesn't cost any bits, but it's the rough border between the "black" area and the actual content that does. So if you can decide between "mod16 with black bars" and "none-mod16 without black bars", the latter probably costs less bits! That's because the "internal" padding that is applied on non-mod16 resolutions is done in a way that costs less bits than the rough border caused by the "black bars" would. Moreover, if you get a non-mod16 resolution after cropping only the "black bars", it is perfectly okay to leave it that way! Anyway, if you want it to be mod16, I would recommend to crop a bit more until you get mod16 (as said before you will loos 15 lines/cols at most). That's what I personally do.

Sharktooth
30th September 2010, 02:13
You can crop at the end of the script.
true, but not always possible.

Bi11
30th September 2010, 04:36
Are there any major technical hurdles that would prevent the possibility of a --video-filter <smart_crop> filter, which automatically chooses the crop parameters such that fixed black bar pixels are removed from the edges of the frame, assuming the input satisfies the necessary criteria (seekable, etc.)?

I guess x264 would have to seek through some random frames until itís satisfied that it can remove as much fixed black bar pixels as possible from the entire video without removing any content. There could be a Ďcautiousí boolean option, which if true, would probably leave some flickering black pixels around the edges if the black border edge isnít sharp, so the default of false could be used instead, but may remove a couple pixel-width lines from the content to avoid flickering edges. The frame would then be internally padded with the appropriate edge-lines to make width and height mod 16.

That option would be very convenient for those who do direct x264 batch encodes of source files, which seems to be part of the purpose of --video-filter. I guess it would also be convenient for general use, such as encoding from Avisynth.

BTW, I'm guessing there isn't anything similar to smart_crop for Avisynth (otherwise I'd go that route)...

simps
30th September 2010, 06:48
It would be cool if Dark Shikari could tell us, how much non-mod16 hurts compression in x264. I know this answer will vary, and will depend on how large the resolution is, how high the bitrate is, and other factors, but anyway, just in average, a rough number...

For example, is he says non-mod16 will cost you about 1% of the bitrate, then I don't think its negligible. If he says something like 0.01% of the bitrate, than its negligible for me.

I hope Dark Shikari can give us this estimate...

creamyhorror
30th September 2010, 07:44
I'm wondering about tradeoffs myself.

Example: a source that, when cropped to remove borders, is 712x476. Consider two choices (there are others, but these two give a common encoded frame size):

1: Rescale to 720x480. You create scaling artifacts, reducing the quality. When you play it back, the encode is scaled to the display size, a second lossy scaling operation.

+: all bits spent on image
-: image degraded (very?) slightly

2: Encode as is (712x476). x264 pads to 720x480 invisibly. No scaling artifacts created, a bit of bitrate is spent encoding the padding. Upon playback, a single lossy scaling operation.

+: no image degradation
-: ~2% of encoded frame area is padding, so less bits spent on image (depends on efficiency of coding the padding)

I don't know a way to calculate/extrapolate the bits spent on encoding padding (since the padding is just part of the frame). It's like asking how many bits 1/4 of a column of macroblocks cost to encode, except that that 1/4 is completely uniform. Is this somehow quantifiable via quantizer comparisons or other black arts?

The number of bits spent on padding might significantly depend on the number of lines cropped, the number of edges cropped, the nature of the content, etc...or it might simply be negligible in most cases. For now I just think that it's better to avoid rescaling and accept the slight bitrate cost premium.

LoRd_MuldeR
30th September 2010, 09:33
I'm wondering about tradeoffs myself.

Example: a source that, when cropped to remove borders, is 712x476. Consider two choices (there are others, but these two give a common encoded frame size):

1: Rescale to 720x480. You create scaling artifacts, reducing the quality. When you play it back, the encode is scaled to the display size, a second lossy scaling operation.

+: all bits spent on image
-: image degraded (very?) slightly

2: Encode as is (712x476). x264 pads to 720x480 invisibly. No scaling artifacts created, a bit of bitrate is spent encoding the padding. Upon playback, a single lossy scaling operation.

+: no image degradation
-: ~2% of encoded frame area is padding, so less bits spent on image (depends on efficiency of coding the padding)

I don't know a way to calculate/extrapolate the bits spent on encoding padding (since the padding is just part of the frame). It's like asking how many bits 1/4 of a column of macroblocks cost to encode, except that that 1/4 is completely uniform. Is this somehow quantifiable via quantizer comparisons or other black arts?

The number of bits spent on padding might significantly depend on the number of lines cropped, the number of edges cropped, the nature of the content, etc...or it might simply be negligible in most cases. For now I just think that it's better to avoid rescaling and accept the slight bitrate cost premium.

It has been said, several times in this thread, that with choice (1) the loss in compression efficiency cause by the required "internal" padding is small and you shouldn't worry about it! If you still do worry, crop it down to 704x464 pixels in order to make it mod16 again. You'll loose only a very tiny portion of the visible area, but you avoid the scaling artifacts in the whole visible area caused by choice (2).


It would be cool if Dark Shikari could tell us, how much non-mod16 hurts compression in x264. I know this answer will vary, and will depend on how large the resolution is, how high the bitrate is, and other factors, but anyway, just in average, a rough number...

You think he would have removed the "non-mod16" warning from x264, if he thinks the loss in compression efficiency caused by non-mod16 resolutions was non-negligible? ;)

J_Darnley
30th September 2010, 09:40
IYou think he would have removed the "non-mod16" warning from x264, if he thinks the loss in compression efficiency caused by non-mod16 resolutions was non-negligible? ;)

Indeed. Also because it spawns [...] discussions like this.

@Bi11: There is an autocrop for avisynth. And I doubt there's going to be one for x264's filter system, you can't seek backwards in it.

kypec
30th September 2010, 09:54
@Bi11: There is an autocrop for avisynth. And I doubt there's going to be one for x264's filter system, you can't seek backwards in it.:goodpost:
Absolutely - x264 is an encoder, it shouldn't be bloated with plethora of filters/pre-/post-processors. That is the job for Avisynth and main reason why Avisynth has been invented in the first place I guess = to do any and all processing you need on your video sources.

thedamager
4th October 2010, 14:35
I would like to know if encoding with non-mod16 resolutions would cause any known player incompatibilities or artifacts (HW or SW).

AlekseiV
4th October 2010, 16:44
I would like to know if encoding with non-mod16 resolutions would cause any known player incompatibilities or artifacts (HW or SW).seeing as any player that supports H264 supports invisible cropping, I very much doubt it. maybe if the width is mod2.

(1920x1080 is actually 1920x1088, invisibly cropped)

elguaxo
4th October 2010, 16:47
I've heard some have problems with mod2. mod4 seems to be safe.

Groucho2004
4th October 2010, 17:57
:goodpost:
Absolutely - x264 is an encoder, it shouldn't be bloated with plethora of filters/pre-/post-processors. That is the job for Avisynth and main reason why Avisynth has been invented in the first place I guess = to do any and all processing you need on your video sources.

Too late, I'm afraid. It has already started.

AlekseiV
4th October 2010, 18:56
Too late, I'm afraid. It has already started../configure --disable-stuff

Dark Shikari
4th October 2010, 20:36
Too late, I'm afraid. It has already started.libx264 is an encoder, and shouldn't be bloated... etc ;)