-m -p -F -q 0.65 -Q -e x264 -r 23.976 -E facc -B 384 -R 44.1 -6 6ch -v -x keyint=240:keyint-min=24:bframes=6:ref=3:mixed-refs=1:subq=5:me=umh:no-fast-pskip=1:trellis=0:no-dct-decimate=1:vbv-maxrate=4900:vbv-bufsize=3000
sorry to perhaps be slightly tangential, but is the -R 44.1 part important, or beneficial at all?
Leo, no-dict-decimate should really have no effect on vbv.
It makes vbv about 10% bigger though, no? Would this not cause some complex parts to max out the vbv limits?
And, frankly, if you use crf for an iPod, you will definitely get some strange things happening. The iPod is just too restrictive buffer wise to expect any kind of consistency with playable crf encodes.
dynaflash, I have found that CRF 60% works very well with 320x240 for iPod onscreen viewing, with not a single problem ever (even when I didn't set vbv limits). Often 640x480 CRF 65% without any vbv limits stutters only occasionally.
For example, 576x320 CRF 58% with vbv limits would probably be almost always completely fine with iPod. I know it's not top quality, but it is still very watchable on iPod, PC and TV, and would be useful for those wanting to keep file size down, or for those who encode a high quality full resolution anamorphic PC (and/or AppleTV compatible) version too, as I do.
Also, I am a bit surprised (happily) if the vbv limits for AppleTV aren't causing any problems in encodes at 65%. I know the iPod limits, 1500 and 2000, are about a third and two thirds of the ApppleTV limits, but 640x368 compared to PAL 720x576 is about 60% of the resolution, or number of macroblocks, so in terms of bits per macroblock it's not hugely different, especially as CRF 65% should be about 50% bigger than CRF 60%. Having said that, I must admit you do have all those nice bframes and cabac to help.
[sorry, I'm not trying to fork this thread]