------------------------------snow------------------------------------------- Posted by akupenguin on 7th February 2005 19:48: There is no list in the manpage or the program. But the options are: vqscale cmp, subcmp, mbcmp: useful values = 0 (SAD), 1 (SSD), 11 (5/3 wavelet), 12 (9/7 wavelet). I find SSD to be best most of the time. pred: 0 (9/7 wavelet), 1 (5/3 wavelet), 2 (13/7 wavelet). I find 9/7 to be best for lossy coding, 5/3 for lossless. qpel: always helps compression, but costs some cpu time both encoding and decoding. v4mv: may or may not improve any given video. v4mv and the wavelet cmp functions are theoretically good, but in practice won't work well until we get OBMC-aware motion estimation. ------------------------------snow------------------------------------------- Posted by akupenguin on 10th January 2005 12:22: quote:Originally posted by Doom9 [B]It'll come as soon as I find a comprehensive list of all the codec parameters, their value ranges and default values./B] Options obeyed by snow: vqscale: range 0.01 .. 255, sane range 1 .. 10. (A given quality in snow needs somewhat lower qscale than the same quality in mpeg4.) default: 0 (lossless). Note that 0 may not be specified; if you want lossless encoding, you must leave out vqscale. (Yes, quantizer can be fractional.) There is no ratecontrol. Constant quantizer is the only mode. pred: 0 => 9/7 wavelet (default). 1 => 5/3 wavelet. 2 => 13/7 wavelet. The different wavelets have slightly different characteristic artifacts. I think 9/7 usually looks best. cmp: full pixel motion comparison function subcmp: hpel/qpel comparison function mbcmp: MB type comparison function Choices that work for snow: 0 (SAD), 1 (SSD), 11 (5/3 wavelet), 12 (9/7 wavelet). Defaults: SAD. While you might think that the wavelet comparators would have an advantage, I find that SSD is usually best (for all 3), with SAD slightly better the remainder of the time. You can add 256 to any of the options to enable chroma_me for that comparison (e.g. mbcmp=257 for SSD with chroma), but I haven't found it to help. qpel: default=off. Always helps, but costs some cpu time both encoding and decoding. v4mv: default=off. Allows smaller motion partitions. The current MB decision algorithm doesn't make very good use of this: it improves quality, but also increases bitrate. (and you could get more quality per bitrate by reducing quantizer instead.) last_pred: range=0-3, default=0. Tries a few extra predicted motion vectors before doing EPZS search. This option has negligible effect on both speed and quality of snow, so just leave it off. (it does, however, help mpeg4.) In short: the best options in almost all cases are vcodec=snow:vstrict=-1:vqscale=$N:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel ------------------------------x264------------------------------------------- Posted by akupenguin on 5th January 2005 19:38: quote:Originally posted by JoeBGermany Oh yes, some functions need some tips for me: 2) Codec a. 2 pass, first pass: a1) Quantizer: 0 is highest quality? I want to encode 1/3 DVD. 0 is highest quality (similar bitrate to huffyuv, though it depends on the amount of motion). I find h264 @ qp=18 to be similar to mpeg4asp @ qp=2, and h264 @ qp=24 to be similar to mpeg4asp @ qp=4. quote:a3) Number of reference frames: 3 -5 ? more is always slightly better, but if you care at all about speed, 3-5 is good. quote:a4) Number of b-frames: 2-3 would be No. We don't have adaptive B-frames yet, so don't use more than 1. quote:a5) I want to use somethimg like adaptive. Is -2 for both ok? is this deblocking? yes, -2 is ok. quote:a7) subpixel refinements: Always QPel brings highest quality? Always QPel is the highest quality, but is only needed on the final encode. For the 1st pass you can set it to medium with negligible loss. quote:a8) Macroblock options: Both for highest quality? b8*8mv and 4*4mv? yes. quote:b. 2 pass, second pass Bitrate: Bitrate for a 1/3 DVD Rip? From a calculation tool? You can set bitrate to whatever you want. That part of encoding hasn't suddenly changed with h264. quote:3) Quant & RC Buffer Size = Bitrate and I should activate "fix" ? Don't touch buffer size unless you know what you're doing. ------------------------------x264------------------------------------------- Posted by snacky on 5th January 2005 19:39: quote:a1) Quantizer: 0 is highest quality? I want to encode 1/3 DVD. quant=0 is a good way to end up with a reencode that's larger than the source. The lowest quants I'd normally consider using are in the 10-15 range. quote:a3) Number of reference frames: 3 -5 ? You can benefit slightly from using a higher number; the speed penalty is pretty minor and in my experience it practically never ends up raising bitrate (unless you turn off CABAC). Lately I usually just use 15. Be aware that 15 is usually only slightly better than 5, if it's better at all. quote:a5) I want to use somethimg like adaptive. Is -2 for both ok? x264 doesn't do adaptive deblocking, but you can tweak deblocking parameters. Don't expect any miracles. It's just a tradeoff of blockiness vs. loss of detail. quote:a7) subpixel refinements: Always QPel brings highest quality? It can never LOWER quality as it might in MPEG-4 ASP (assuming a given bitrate, that is). Asking for more subp refinement usually makes a significant difference. The difference between subq=1 vs subq=5 is often a couple percent in bitrate plus a little PSNR, but the speed difference is very big too. ------------------------------x264, reference frames------------------------- Posted by akupenguin on 5th January 2005 22:00: Results: for real movies, I have seen up to about 5% reduced bitrate for 4 refs vs 1, and up to 10% for 15 refs vs 1. (These comparisons run with no B-frames, all other options at max (cabac,subq=5)) While I haven't done a detailed study of how refs are actually used, I think I am qualified to guess. There are two uses for multiple reference frames: One is to just find blocks that more closely match the current in a scene with somewhat chaotic motion (like most live-action). This produces only a few % difference in bitrate, but only requires a few ref frames (2-4). The other is to encode scenes where one object obscures another but later moves out of the way. With sufficient refs, you can encode the backdrop as a mv from long ago, but without sufficient refs it has to be intra. This can benefit from any number of refs, easily up to 15 (and could use even more with long-term refs). The only limit is that at high numbers, it starts to get less efficient because of the number of bits required to encode which ref it used. (This is where CABAC helps. It could also be improved with adaptive ref marking and/or ref list reordering, whenever I get around to implementing those.) ------------------------------x264 buffer underflow-------------------------- Re: buffer underflow quote:Originally posted by Yong What problem with my x264 encoding options? During first-pass, mencoder display some message: buffer underflow -xxxxx... Will it hurt quality? That means the CBR ratecontrol couldn't meet your specified bitrate (for some scene) due to the qp_min=26. It will not hurt quality unless your 2nd pass decides to use quants < 26. ------------------------------x264 deblocking-------------------------------- Posted by akupenguin on 10th January 2005 19:08: Deblocking always smooths, never sharpens. The strength and threshold are always adaptive based on quantizer. alpha=0,beta=0 is tuned for optimal PSNR on most sources. Other values tell it to use the strength and threshold tables from a different quantizer. So qp=25,alpha=-5,beta=-5 uses the same deblocking as qp=20,alpha=0,beta=0. Since higher quantizer => more artifacts => more deblocking needed, higher values of alpha & beta do stronger deblocking. (Note that since h264 uses a logarithmic quantizer, adding/subtracting N from it has the same effect independent of what the original quant was.) If qp+alpha <= 15 or qp+beta <= 15, deblocking is completely disabled for that frame. As for what exactly the parameters do: Consider each potential vertical/horizontal edge in the picture (between macroblocks, or between motion partitions within a macroblock). Derive a threshold (based on qp, beta, and type of block) and strength (based on qp, alpha, and type of block). If the variation within the adjacent blocks is less than threshold, and the difference across the edge is less than strength, then filter this edge. Filter means apply a 6tap blur perpendicular to the edge, but limit the amount of change to any one pixel based on strength. The effect of block type: Edges between non-coded blocks of similar MV are not filtered (because they were deblocked in the previous frame). Non-coded blocks that differ by more than 1 pixel worth of MV are filtered weakly. Normal inter blocks are filtered more. Intra blocks are filtered most. edit: I got alpha and beta swapped. ------------------------------x264 rc buffer---------------------------------- Posted by akupenguin on 25th October 2004 18:48: The default rc_buffer_size is 1 second's worth of bits, so you could just leave it alone. But if you do want to specify it, it's measured in kbits, not seconds, so you'd want something around rc_buffer_size=450. In both CBR and multi-pass, setting rc_buffer_size too small will cause wild fluctuations in quantizer, because even a small error in predicting one frame size will completely empty or fill the buffer. The optimal buffer in my tests was around .5-1 second for CBR, or 1-2 seconds for multi-pass. So I selected a default of 1 second, and you shouldn't have to change it unless you have some special restrictions. Now, in your case it didn't actuall kill your encode, because x264 recognizes 1kbit as a rediculously small buffer (it's less than the size of one frame), emits a warning message, and uses .5 seconds worth of bits instead. ------------------------------x264 1st pass----------------------------------- to get a better speed is it still possible to use different subq values for 1st and 2nd pass? if yes how big do you think can the difference be (eg for subq=5)? Yes, that still works, and probably won't ever change. (Maybe when I extend 2pass to do more than ratecontrol.) I've seen good results even from subq=1:no4x4mv:nob8x8mv on the 1st pass. If you want to be conservative, then subq=3:no4x4mv. And theoretically speaking, I would expect that the only option to really matter on the 1st pass would be frameref, since it can affect scenecut detection. Even then, you don't lose too much from 1st pass frameref=1, except in special cases. ------------------------------x264 skip--------------------------------------- Posted by akupenguin on 29th December 2004 23:04: Weirdness... it seems that -noskip sometimes (whenever there are B-frames?) adds null frames at the beginning. Try with harddup and -mc 0 but without -noskip. You might try filing a bugreport, but most of the devs refuse to touch mencoder. I'm not sure I could fix it either. Reference frame signalling is now fixed. (It was unconditionally allowing an extra ref for B-frames.) Green tint is acknowledged. I don't know what's causing it. ------------------------------x264 frame types decision----------------------- Posted by akupenguin on 1st January 2005 12:03: quote:Originally posted by Yong I tried many time with the latest mplayer build, but no b-frame on output video... Frame types are decided on the 1st pass. You didn't enable bframes there. ------------------------------x264 sane values-------------------------------- Posted by akupenguin on 2nd January 2005 22:38: ip_factor: allows 1..10. sane values: 1.2 .. 1.5 pb_factor: allows 1..10. sane values: 1 .. 1.4 qp_step: allows 1 .. 51. sane values: 1 .. 3 rc_buffer_size: allows (bitrate/fps) .. bignum. sane values: (bitrate/2) .. (bitrate*2) rc_buffer_init: I just changed this to be a fraction (0..1) (previously it was in units of kbit). I set the default to 0.25 because most movies begin with some seconds of blackness or otherwise no motion, so the buffer will quickly fill up anyway. It you're encoding a clip that starts right away, you might set rc_buffer_init to 0.5 or more. (Only matters for CBR.) quote:Meaning when you are doing your onpass with bitrate 450 kbits/second go for 225 kbits/second to 450 kbits/second, and to 450 kbits/second to 900 kbits/second for multipass encoding right, except that the units of rc_buffer_size are kbit, not kbit/second. quote:Also, the ratecontrol in x264 is already excellent - test the above and you will see (not usually more than 3 kbps out in my tests on a reasonable length encode i.e. at least 1 hour) Sure, it can accurately meet your specified average bitrate. That's easy. (I have no idea why WMV9 and VP6 have such issues with it.) But that doesn't mean it's good ratecontrol: The reason 2pass is better than 1 is that the codec can adjust the distribution of bits based on the complexity of the scene. And my distribution algorithm was mostly pasted from libavcodec, with only minor tweaks for H.264.