x264 now allows non-mod16 resolutions!

[hpn]

As of revision 327 x264 allows non-mod16* resolutions. No more "width % 16 != 0 or height % 16 != 0" error messages

Now we can use:

mod16 - valid (example 720x432)
mod8 - valid (example 712x424)
mod4 - valid (example 716x428)
width mod4, height mod2 - valid (example 716x430)
width mod2, height mod4 - invalid (example 718x428) -> Avisynth error: YV12 images for output must have a width divisible by 4 (use crop)!

However if either width or height is not divisible by 16, compression will suffer, so if possible always use mod16.

*note: The module (mod) is the remainder produced by dividing two integers. For example if we treat 20 / 6 as an integer divison, the quotient is 3 (rather than 3.333..) and the remainder is 2.

[celtic_druid]

http://ffdshow.faireal.net/mirror/x2...revision327.7z
http://ffdshow.faireal.net/mirror/x264/X264VFW.exe

[leowai]

Thanks for the news. Very Good news.

Cropping with mod16 resolution is too restricted. Now, x264 has more attractive reason to use, mod4 resolution! (Just same as XviD?).

[Czarek Kwasny]

This is just great!!
I find it very useful for encoding in HDTV res => 1920x1080
thanks a lot!

[hpn]

Originally Posted by hpn

width mod2, height mod4 - invalid (example 718x428) -> Avisynth error: YV12 images for output must have a width divisible by 4 (use crop)!

Actually if you want both width and height to be mod2, it's possible to add ConvertToRGB32() to your avs script like this:

LoadPlugin("Z:\Program Files\dgmpgdec\DGDecode.dll")
mpeg2source("G:\DVD\a.d2v")
ConvertToRGB32()
crop(0,72,718,430)

Then open the script in VirtualDub and in menu "Video"->"Color Depth" under "Output format to compressor/display" select "4:2:0 planar". Now you'll be able to make mod2 encodes with x264. I don't know if this is the best way to work around this mod2 problem. I still can't find a way to make width/height mod2 with CLI, no matter if I use ConvertToRGB32() or not. CLI returns:
avis [error]: unsupported input format (DIB )
could not open input file 'b.avs'

[akupenguin]

avs2yuv can handle mod2 YV12 output.

ConvertToRGB has no business in any filterchain that's going to be compressed. Cropping away two pixels will lose much less information than a conversion to RGB and back.

[hpn]

Thank you, akupenguin. Your help is invaluable as always. I was very suspicious about converting to RGB, but that was the first thing I tried and It worked. I'll try again with avs2yuv

[bond]

great stuff!

but i have two questions:
1) what does x264 use to stuff the frame for getting a mod16 resolution? i see that mplayer displays a green line
2) pengvado, will you add frame cropping support to libavcodec?

[Sirber]

sweeeeeeeeeeeeeet

[akupenguin]

x264 stuffs by replicating edge pixels, and libavcodec already supports cropping.

[bond]

Originally Posted by akupenguin

x264 stuffs by replicating edge pixels

thx

and libavcodec already supports cropping.

hm not sure if this works correctly:
- in ffdshow i see pink artefacts and black borders at the top and the bottom (its frame_crop_top_offset: 0 and frame_crop_bottom_offset: 3 in the sps tough)
- in mplayer i dont see pink artefacts, but a green border at the bottom of the frame

i attached screenshots showing this

[omion]

Originally Posted by akupenguin

x264 stuffs by replicating edge pixels, and libavcodec already supports cropping.

Would it be more efficient to mirror the edge pixels?

I wrote a JPEG library (based on libjpeg) and found that proper mirroring will both increase quality on the edge and decrease file size (not by much, mind you, but every bit counts)

What I did:
Replicate the edge pixel to the nearest power of 2, then mirror those pixels to the next power of 2, then mirror again, etc..
For example:

[a,b,c,d,e] -> [a,b,c,d,e,e,e,e]
[a,b,c,d]   -> [a,b,c,d,d,c,b,a]
[a,b,c]     -> [a,b,c,c,c,c,b,a]
[a,b]       -> [a,b,b,a,a,b,b,a] (*)

This is good for compression because if the block is evenly symmetric then 4 of the 8 1D DCT coefficients must be 0. I don't know how well the 4x4 transform that AVC uses will benifit from it, but it should be similar.

Perhaps mirroring to mod 4, then replicating only the DC component to other 4x4 blocks... just an idea.

(*) Due to the way the DCT is designed, the DCT of this block is actually lossless, as long as the quantizers are low enough. I made a "lossless JPEG" proof-of-concept which mirrored every 2x2 input block into an 8x8 JPEG block, which was capable of perfect reconstruction.

[akupenguin]

Mirroring is good for spatial transforms, but hurts motion compensation.

bond: I can't reproduce it.

[ChronoCross]

Originally Posted by akupenguin

bond: I can't reproduce it.

@bond
did you use any special setting combinations? or was this default settings with that particular res?

[omion]

Originally Posted by akupenguin

Mirroring is good for spatial transforms, but hurts motion compensation.

Ah. I didn't think of that. Thanks for clearing it up.

[bond]

hm my settings were the following:

x264 --bitrate 770 --ratetol 1 --bframe 3 --b-pyramid --ref 5 --mixed-refs --filter -5:-5 --8x8dct --analyse all --weightb --progress -o raw.264 input.avs

my mplayer is the latest cvs. can noone reproduce the greenline in mplayer neither?

i updated my ffdshow to a compile from 30 september and the pinkyness is gone
still there is the small black bar on the top and bottom of the frame. is this a problem?

[sh0dan]

Right now the MOD4 restriction in AviSynth is there because no codec has been capable of decoding this. Or at least XviD hasn't. We can implement an override switch for AviSynth 2.6, so you can leave out the YUV->RGB->YUV conversion.

[hpn]

Originally Posted by bond

still there is the small black bar on the top and bottom of the frame. is this a problem?

I just tried your exact CLI settings with mod8 (712x424) and mod4 (716x428). Both raw encodes play fine with Mplayer without any black or green lines. But I remember I had the same green lines problem about a year ago. Can't remember how I solved it, but something definitely had gotten borked among the numerous pieces of software that I usually install/re/un/install almost daily. One possible reason for the green/pink lines could be the video drivers, so reinstalling them may help or if you have recently updated them you could try to revert to some old version. I recently had problems with a "brand new" but buggy nVidia Geforce drivers so I'm now with an age old version that seems to work fine with my hardware.

Originally Posted by sh0dan

We can implement an override switch for AviSynth 2.6, so you can leave out the YUV->RGB->YUV conversion.

Good news!

[Sharktooth]

usually the green line is due to improperly used filters (like deinterlacers) or other filters that does not support the selected resolution.

[ariga]

I see the "green line" problem if non-mod16 height in MPC 6.4.9.0 with VMR7/VMR9 (renderless)+CoreAVC 0.4

No problems with overlay or windowed output.