compressing, avisynth etc. tips?

[Overture]

well i happen to think that im a decent encoder and whatnot, but nowhere the best of course:3 enough to get by. so i wanted to post this just to get some more tips from better people:D i figure you can never kno too much right!!!.. .......or can youO-o well to start, i of course make most of my amvs with dvds, use avisynth, vdub and all that jazz. as for my avi script, a typical script id use for most situations i guess would be

AMVDeint(mode=2)
TTempSmooth()
toon()...sometimes
lsfmod()
undot()
spline36Resize(848,480)
converttorgb32()

ive seen heavier filtering done, tho i dont necessarily want to overfilter my footage either. so depending, ill throw in a toon or stronger sharpeners. anyways, any suggestions for better scripting? different plugins? just for something in general. i havent really experimented with alot of the avisynth filters yet so anything anyone would recommend would be kew:3

ALSO, atm, im trying to compress an amv down to 10MB per 1minute of video. besides filtering to better compressibility, resizing (i wanna stick to 848,480 tho) any suggestions to getting a low file size with the least quality loss? i edit lossless blah blah. and use zarxgui. for now im trying out higher quantizers, around 26 gives me the file size, but quality loss is kinda doodoo:l passable i guess, but not what id want:3 i even tried turning up the deblocking.

any suggestions for my scripting or better compressibility? im not looking for a miracle, just wanted to broaden my knowledge and skilsl>:) and stuff XD sorry for such a broad topic lol. thought this might be interesting:3

[Zarxrax]

Instead of resizing your video to 848x480, just leave it at whatever resolution it's at and set the sample aspect ratio in zarx264gui to 16:9.
Also, some videos just don't compress that well.

[Overture]

Instead of resizing your video to 848x480, just leave it at whatever resolution it's at and set the sample aspect ratio in zarx264gui to 16:9.
Also, some videos just don't compress that well.

hmmm okay. tho this time on the video im currently working on, i already made my huffyuv files:D but ill definitely remember that next time. thanx! so i just rip and filter my footage without ever doing any cropping and resizing right? just keep it as the dvd PAR and the resizing should work and whats the benefit? im guessing its more accurate or less quality loss? thanx again

[Qyot27]

When scripting, less is more, more or less. It depends on what the source needs, and generally speaking, new (say, post-2004) releases require very little in the way of cleaning up, as they're already mostly well-authored nowadays. Some companies may still have problems with this, but by and large crappy authoring jobs are on the decline and have been for years.

(or you could just get the Japanese R2s and cut out the middle-man, which also nets you even fewer chances of botched releases)



As far as compressibility, you need to make a decision about what is more important to you - speed, or quality at a specific file size. I always use CRF 18 for my distro encodes, but I also use such insane settings for almost everything else that I still roughly hit the 10MB-per-minute mark - then again I'm not effects-happy either, so I don't have that sucking away my bitrate. I also make sure I use the newest build of x264 (actually to the point of compiling it myself from git).

This could certainly use some updating, as it doesn't take the additions/changes to x264 from recent months into consideration (deprecation of some options, mb-tree, Auto-VAQ, etc. - especially mb-tree, since b-pyramid hasn't been fixed to work with it yet, last I knew):

x264.exe --crf 18.0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock 1:1 --subme 9 --trellis 2 --partitions all --8x8dct --scenecut 100 --threads auto --thread-input --sar 1:1 --aud --progress --no-dct-decimate --no-psnr --no-ssim --output "output.mp4" "input.avs"

The idea of anamorphic video (storing the video as 720x480 and flagging it so it plays back as 848x480) is to optimize bitrate usage. Compressing a 720x480 frame with high quality is easier than if it were 848x480, so the bitrate can be better handled, and you may not even need as many bits to do it - resulting in a smaller filesize.

[Overture]

When scripting, less is more, more or less. It depends on what the source needs, and generally speaking, new (say, post-2004) releases require very little in the way of cleaning up, as they're already mostly well-authored nowadays. Some companies may still have problems with this, but by and large crappy authoring jobs are on the decline and have been for years.

i see. which is also why i try to use a little lighter settings(not counting the toon and sharpening whatnot, tho i kinda like the look once in a while in some scenes, tho it butchers others:l) andi also veered away from using deen anymore since even at really low settings, it seemed unnecessary at all and it messes with my colors. so instead i stick to ttempsmooth() most of the time. still gotta try out others on day tho when im not lazy:3

I always use CRF 18 for my distro encodes, but I also use such insane settings for almost everything else that I still roughly hit the 10MB-per-minute mark - then again I'm not effects-happy either, so I don't have that sucking away my bitrate. I also make sure I use the newest build of x264 (actually to the point of compiling it myself from git)

well so far my new amv that i want to hit 10mb per minute isnt quite done... BUT its extremely fx happy as its going to be 80 percent done it after effectsO-o so thats gonna make it more harder. but im testing this on an old amv's lossless copy that i have and while mildly fx happy, i could only get it to hit my mark using --crf 25. and using --crf 18 with insane settings, its a 2 minute vid and its 47.8 MB. so its nowhere near 10MB per minute. i still gotta update my zarxgui tho. and i dont kno much about command lines but i basically try not to touch my settings in zg unless i turn up the deblocking since i heard it can increase compressibility, tho i usually dont. so i would i change my settings to something like yours? and from wat you said so far, it seems if my settings were the same as yours, then would it compress as good as it does for you? or is there more to it? cuz 18 is just such a large file size for me. speed isnt a factor for me if i can get my vid to be 10mb per minute. any suggestions?

[Zarxrax]

Testing on an older video is pointless, as every source compresses differently. The settings he gave are from an older version of x264, and that commandline wont really work anymore. Just make sure you have the latest zarx264gui (see my signature), and you should be fine. But you can't necessarily expect it to look good at 10mb/minute. Some sources just NEED more than that.

[Overture]

[quote][/quote]hhmmm so in the end, there isnt much more to drastically decreasing file size other then the filtering, quantizers, etc. if i just filter my footage, decide on my PAR, and choose a --crf, i cant really do a whole lot else to keep my quality up thatll drastically help. the quality that i achieve so far to compress so small isnt HORRIBLE, tho i just wanted to make sure im not really missing out on any more of a quality gain than i could already be having. well for future amv's i guess ill just keep trying to save bitrate and stuff so i can compress it stronger or something. thanx tho for the tipsXD really appreciated!

[Qyot27]

i see. which is also why i try to use a little lighter settings(not counting the toon and sharpening whatnot, tho i kinda like the look once in a while in some scenes, tho it butchers others:l) andi also veered away from using deen anymore since even at really low settings, it seemed unnecessary at all and it messes with my colors. so instead i stick to ttempsmooth() most of the time. still gotta try out others on day tho when im not lazy:3

Well, I still use deen. But that's sort of inconsequential. The major key in filtering is not just seeing if something helps, but identifying the actual problem and then using the filters to solve it. It's never a case of 'it just looks wrong' or 'it looks dirty', except at a first glance - the individual issues of the source should be known and the filters specifically selected for them. So it should look more like: 'it's got nasty banding', 'it's got horrible rainbowing', 'look at that dot crawl', repeat on and on for the other stuff - mosquito noise (which is pretty hard to see, and what I usually use deen for as a preventative baseline measure), yellowing, etc.

Going back over, this is approximately how it would look on a newer build (I used revision 1259 as the base here, as that's the newest in MeGUI's pipeline, even though I've compiled my own build of revision 1271):

x264.exe --profile high --preset placebo --crf 18.0 --deblock 1:1 --bframes 16 --b-adapt 2 --direct auto --b-bias 0 --scenecut 100 --ref 16 --rc-lookahead 40 --aq-mode 2 --aq-strength 1.0 --merange 16 --subme 10 --partitions all --trellis 2 --no-dct-decimate --no-fast-pskip --output "output.mp4" "input.avs"

As for choosing a CRF value, if 18 is too high and 25/26 looks too horrible, you can try to find a middle-ground there - 20 is often recommended, and even at 22 I'm sure it would be reasonable. But including the recent readjustings of CRF due to things like AutoVAQ and so on, you may find that such settings on a new build, even using CRF 18, will produce smaller files than they would have before.

With those additions, though, you might want to hold off a bit on the builds from/since this past summer, as A) --b-pyramid hasn't been fixed to work with --mb-tree, and B) reportedly --mb-tree creates some issues with fades, and the patch to fix this (--weightp, or Weighted P-Prediction) hasn't been finished yet. Of course, that's just if you want to take advantage of --mb-tree in the first place. If that doesn't matter, don't use --mb-tree, and you can use --b-pyramid without worrying. As to why you might want to rethink that decision, though, look at this example of a 67kbps encode that was posted in the --mb-tree testing thread:
http://mirror05.x264.nl/Dark/Flash/lowbitrateanime.html

(the point being that if it can make 67kbps look that good, imagine the gains on sane bitrates)

[Overture]

With those additions, though, you might want to hold off a bit on the builds from/since this past summer, as A) --b-pyramid hasn't been fixed to work with --mb-tree, and B) reportedly --mb-tree creates some issues with fades, and the patch to fix this (--weightp, or Weighted P-Prediction) hasn't been finished yet. Of course, that's just if you want to take advantage of --mb-tree in the first place. If that doesn't matter, don't use --mb-tree, and you can use --b-pyramid without worrying. As to why you might want to rethink that decision, though, look at this example of a 67kbps encode that was posted in the --mb-tree testing thread:
http://mirror05.x264.nl/Dark/Flash/lowbitrateanime.html

HOLY CRAPo-O and thats at 67kbps!! damn, well for now quality IS important, but my first priority is keeping this amv at 10mb per minute, so for now i guess ill just keep from using --mb-tree and save my b frames:D then later when the file size doesnt matter much anymore ill take advantage of --mb-tree:) now i hope i can manage to put all this to use and get my CRF lower than 25:l

so lemme get this straight tho, --mb-tree is on the newer versions of x264 right? or how do i disable --mb-tree so i can use b-pyramid instead? thanx! this info is really helpin alotXD

[Zarxrax]

B-pyramid is fairly useless, and mb-tree gives quite nice gains. I don't think there's really a whole lot of reason to give up mb-tree for bpyramid.