PDA

View Full Version : What if it's not a multiple of 16?


NerdWithNoLife
8th May 2008, 23:33
I've been searching for a while; maybe I'm using the wrong keywords. But what I want to know is - how exactly will x264 compression suffer (especially motion search) if the video is not a multiple of 16? I ask for a couple reasons. One, in my tests YouTube will not give the "HQ" (ha ha) option in a 480x352 frame by default, but they will with 480x360. Two, 1920x1080 doesn't adhere to the multiple of 16 rule.

I'm just getting on this x264 train, so thanks very much to anyone who explains what will go wrong if the video is a multiple of 8, but not 16. Will quality be reduced throughout the frame or just around the edges? Or something else?

Dark Shikari
8th May 2008, 23:43
It'll have to pad a few lines of pixels. That's it. Minimal efficiency loss.

shae
12th May 2008, 23:30
It's actually stored as 1920x1088, I hear. (BTW, are those 8 pixels accessible somehow?)

It'll have to pad a few lines of pixels.Is there a standard way to pad it (say repeating the last line) or is each encoder free to use whatever it wants?

Dark Shikari
12th May 2008, 23:41
It's actually stored as 1920x1088, I hear. (BTW, are those 8 pixels accessible somehow?)Sure, if you remove the crop flags from the stream or use a decoder which lets you explicitly disable the cropping.
Is there a standard way to pad it (say repeating the last line) or is each encoder free to use whatever it wants?There is a standard way, but it isn't required. Repeating the last line is the "standard way," which x264 does. Mirroring would be better for an intra-only codec.

shae
12th May 2008, 23:53
Sure, if you remove the crop flags from the stream or use a decoder which lets you explicitly disable the cropping.Which AVC (and ASP) decoder can do that?

There is a standard way, but it isn't required. Repeating the last line is the "standard way," which x264 does. Mirroring would be better for an intra-only codec.Interesting. Are/were there any encoders filling it with black? :)

Dark Shikari
12th May 2008, 23:55
Which AVC (and ASP) decoder can do that for?I have no idea.Interesting. Are/were there any encoders filling it with black? :)Doubtful, but there's probably some retarded one that does.

unskinnyboy
13th May 2008, 00:11
Are/were there any encoders filling it with black? :)No decent encoder should do this, because, padding it with black would result in a sharp transition from the picture pixels, and this sharp edge will result in a quality/compression loss. Interpolating the edge pixels is how most encoders would handle it (e.g. Xvid, x264 etc).

shae
13th May 2008, 01:04
No decent encoder should do this,Yeah. That's why I wondered. :)

tetsuo55
14th May 2008, 16:55
Not using a multple of 16 also completely breaks hardware compatibility.

unskinnyboy
14th May 2008, 18:13
Not using a multple of 16 also completely breaks hardware compatibility.That might be too strong a statement. Older standalones had a problem with this, but the newer ones (at least most of them) should be able to play non-MoD16 encodes without any issues.

ajp_anton
14th May 2008, 19:45
Not using a multple of 16 also completely breaks hardware compatibility.Aren't Blu-ray and HD DVD both non-mod16...?

shae
15th May 2008, 17:10
Aren't Blu-ray and HD DVD both non-mod16...?1920, 1280, 720 all divide fine. 1080 is stored as 1088.

audyovydeo
15th May 2008, 17:55
Which AVC (and ASP) decoder can do that?

CoreAVC has an option :

"Crop 1088 to 1080"

which implies that it expects 1088 streams as input.

cheers
audyovydeo

ajp_anton
16th May 2008, 03:40
1920, 1280, 720 all divide fine. 1080 is stored as 1088.Yes, but so does every other non-mod16 resolution (not 1088, but the next number divisible by 16).
So what's the difference between "Not using a multple of 16" and 1920x1080?

unskinnyboy
16th May 2008, 08:02
So what's the difference between "Not using a multple of 16" and 1920x1080?1080p is actually encoded and stored as 1920x1088, so what was fed to the encoder was really MoD16. Here, in this thread, we are talking about the possible disadvantages of feeding an AVC encoder (x264, in particular), a really non-MoD16 stream. There is certainly a difference between the two cases.

nm
16th May 2008, 11:49
1080p is actually encoded and stored as 1920x1088, so what was fed to the encoder was really MoD16. Here, in this thread, we are talking about the possible disadvantages of feeding an AVC encoder (x264, in particular), a really non-MoD16 stream. There is certainly a difference between the two cases.
If the encoder is fed any non-mod16 video, it pads it with extra lines, encodes the mod-16 video and sets crop flags. There is no difference to the 1080p case except that a broken decoder or player could be programmed to handle 1080i/p, but no other non-mod16 resolutions.

Dark Shikari
16th May 2008, 12:15
1080p is actually encoded and stored as 1920x1088, so what was fed to the encoder was really MoD16. Here, in this thread, we are talking about the possible disadvantages of feeding an AVC encoder (x264, in particular), a really non-MoD16 stream. There is certainly a difference between the two cases.No, they're exactly the same thing. There is no such thing as a "non-mod16 stream"; that's just a mod16 stream with crop flags. 1080p is a mod16 stream with crop flags.

benwaggoner
17th May 2008, 22:29
Which AVC (and ASP) decoder can do that?

Interesting. Are/were there any encoders filling it with black? :)
There used to be some that did that back in the day. Apple's SP encoder, maybe? I've seen edge abberations on the bottom that indicate black padding with MPEG-1 and MPEG-2 encodings before, but don't recall the encoders used.

Agreed this is a Bad Thing. I noodled around for an algorithm a while back to figure out a best fit padding interpolation method that'd figure out what padding would give optimal RD, but never got very far with it.

moviefan
19th May 2008, 21:23
If I wanted to encode a video in 1080p for Blu-ray compatibility, would I add a black border so that the final height is 1088 or 1080 in AviSynth and feed it to x264? I would author it with TsMuxer... DGAVCDec tells me my video is 1920x1080...

Irakli
19th May 2008, 21:55
If I wanted to encode a video in 1080p for Blu-ray compatibility, would I add a black border so that the final height is 1088 or 1080 in AviSynth and feed it to x264?

It is certainly better to feed x264 with 1080p in any case.

unskinnyboy
20th May 2008, 01:24
If I wanted to encode a video in 1080p for Blu-ray compatibility, would I add a black border so that the final height is 1088 or 1080 in AviSynth and feed it to x264? I would author it with TsMuxer... DGAVCDec tells me my video is 1920x1080...

It is certainly better to feed x264 with 1080p in any case....and that's because if you have a non-MoD16 resolution as input, you better let x264 internally interpolate the edge pixels to the nearest MoD16 resolution and encode than to pad it yourself with black borders and ruin quality/compressibility.

moviefan
20th May 2008, 21:41
Hm? I'm still not sure, what to do... leave the video at 1920x1080 or add borders to 1920x1088 and encode? And which resolution do I need to mux it with TsMuxer for Blu-ray compliancy?

ajp_anton
20th May 2008, 23:58
You encode it at 1920x1080, because that will let x264 create the "borders" more efficiently than you would be able to do yourself.

The video can't and never will be 1920x1080 because either you add the extra 8 pixels or the encoder will.

vmrsss
21st May 2008, 10:57
No, they're exactly the same thing. There is no such thing as a "non-mod16 stream"; that's just a mod16 stream with crop flags. 1080p is a mod16 stream with crop flags.

Ah, so why is there such a stark warning "the encoding will suffer"? From what you say when you have non-mod16 you are after all better off to leave it that way than to upscale to mod16 (though downscaling would still be better, I expect).

As a curiosity, would these mechanisms (interpolation and crop flags) work with other codecs? I am thinking explicitly of DVDs/MPEG2, where you invariably need to fill some black padding or to rescale to get to the required frame size. Could an encoder simply fill the space with suitably chosen pixels and then set crop flags? Is there such a thing as a pad flag?

Dark Shikari
21st May 2008, 15:39
As a curiosity, would these mechanisms (interpolation and crop flags) work with other codecs? I am thinking explicitly of DVDs/MPEG2, where you invariably need to fill some black padding or to rescale to get to the required frame size. Could an encoder simply fill the space with suitably chosen pixels and then set crop flags? Is there such a thing as a pad flag?That's how most formats with non-mod16 support work (at least the ones that use macroblocks, i.e. MPEG-like formats).

moviefan
21st May 2008, 18:10
So is there a way to crop my video so that there are no black borders anymore and let the encoder pad it to 1080 instead of doing it myself? I'm thinking of efficiency since you said the encoder can do the padding more efficiently... And how to I set the pad flag in x264? When I have a video at 1920x1080 and encode it, it still has this resolution and not 1920x1088, so how does this fit to your comment, x264 would pad it to a mod16 resolution anyhow?

Dark Shikari
21st May 2008, 18:37
So is there a way to crop my video so that there are no black borders anymore and let the encoder pad it to 1080 instead of doing it myself? I'm thinking of efficiency since you said the encoder can do the padding more efficiently... And how to I set the pad flag in x264? When I have a video at 1920x1080 and encode it, it still has this resolution and not 1920x1088, so how does this fit to your comment, x264 would pad it to a mod16 resolution anyhow?It pads it and puts crop flags on the stream so that on playback, the decoder will crop it back to 1080p.