question: faster encoding..?

here goes: is there any way of doing a one pass (100%) quality based encode, and still write a motion-log file? so i can add all the timeconsuming resize/cleanup filters in the first pass, and then in the second pass transcode the first-pass encode using the motion-log to reach my desired filesize. not running any filters for the second pass should save a lot of time. if it's possible, will this method affect the quality of the encode compared to a standard 2-pass encode?

1-pass doesn't generate a stats file, and even if it did, you'd only save time if you recompressed the lossy file - not a good idea at all in certain cases (depending on the speed of the filters you choose), it's faster all-in to save your filtered video to an intermediate lossless format before doing a two-pass on the already-filtered (but lossless) video - basically, the time-saving is as your thread identifies, gained through not applying slow filters more than once for fast filters, though, the equation may change, ymmv!

Hi, You could achieve this result if you, uncheck Discard 1st pass in the Xvid Config and compress the resulting file in the Second Pass. I did a few experiments with that some time back, it is definitely faster but the quality was not as good (the result of 1st pass is 100% quality=Quantizer 2 but still it is not lossless). IMHO the reason for those problems is that because of the lossy compression the stats file you created in the first pass does not exactly fit the material you use in the second pass. Cheers Cantide

Maybe it's time someone implements an option to make the first pass save with constant quant 1 (even if internally it performs its calculation on using quantizer 2 it can save a different bitstrean. That 'fork' would take less overhead time than the one taken by a full prealable huffyv12 encode (before 1st pass, for saving filtered), and also 2 huffyv12 decodes (1st pass and 2nd pass) would be replaced by one xvid quant1 decode (2nd pass)). And if quant1 isn't enough for quality, to also save this 'forked' stream with some HQ matrix (for ex Andreas 78er, or that we could choose, or maybe the divided-by-two matrix of the one choosen, in order to have the same kind of quantization artifacts generated [if it doesn't raise overflow errors also...]). Syskin, Koepi, what do you think of it ? Would it be too hard to implement ?

thanks for the input. the reason for asking is that i recently encoded a movie, and the 1st pass alone took about 16 houres due to the filtering (4-5 is normal). my audio/video encoding tools are located on a different os/partition, and i need my computer for other activities. i'll try to be more specific: let's say i'm encoding something to xvid 640x272 with 750 bitrate. can i do the 1st pass at 800-1000 bitrate (being sure the peak bitrate is high enough), and use the 1st pass result together with the logfile to transcode it to my desired bitrate (750)? i'll try what Cantide suggested (uncheck discard 1st pass in the xvid config and compress the resulting file in the 2nd pass). if this doesn't work i'll have to consider a hardware upgrade ;) .

Tip: if you have the HD space (a few gigs per movie), filter to a lossless codec like huffyuv or VBLE. You can find them by using the search function. This will in essence create a 3-pass encoding scheme, but your two last passes will probably speed up considerably.

What i am suggesting is certainly no good for a 1 CD rip, but for a 2 CD rip you may test anamorphic encoding into matroska container without any resizing. I am not sure though if it really could be a speed advantage, for sure not with all the options i turned on ( VHQ = 4 , Q-PEL, 5 b-frames ) etc, as the higher number of pixels ( 720 x 432 ) will more than eat away the small speed advantage from not having to use a resizing filter, but with your 1 pass quality based encoding it may be an option to test. Latest mkvmerger binaries will allow you to set the corresponding AR flag in the matroska track header when transmuxing your AVI into MKV, and both mplayer on Linux and TCMP with matrosks CDL plugin will read the flag and auto-correct AR for playback. Dont forget to use h.263 quants .... EDIT : sorry, i misunderstood your intentions. You are not aiming to make a 1 pass encoding, you would like to make the 2nd pass from your 1st pass AVI. Thats possible in principal, but not recommended, and was discussed ages ago already ( for nandub, in the old nandub forums ), as you would add a lot of noise from reencoding another encode ...

edit: a doublepost ^^ sorry

well. But I think a 2pass-1st pass option by side of 'discard first pass results' could be 'q1 encode as first pass result'. As this would be quicker than using vble (one pass less), and the quality would be good enough (don't forget the source was MPEG-2 which theoretically can't beat q1 in quality).