Saving time with slow filters

I've been wondering. When using gknot, does it apply all the filters you use twice, once for each pass? i.e. could I save time by doing the following: - Create the avs file in gknot with whatever filters, load it in vdub and encode the output using huffyuv to an avi - Load the resulting avi in gknot, comment out most of the new avs and encode as normal I think this would save a lot of time, especially with one or more slow filters, e.g. i am wanting to use pixiedust followed by c3d/moviehq to squeeze 3 hrs of a comedy series onto one cd. If you did this, you would only need to apply the filters once, before you start any encoding, and the total time would be shorter. Or does gknot do this anyway? I don't know.

Hi- does it apply all the filters you use twice, once for each pass? Yes it does. Interesting question. GKnot will still run 2 more passes after loading the Huffy .avi, so you're running 3 passes in all; one really slow one encoding to Huffy, and 2 real fast ones since you're recompressing an .avi with no filters added. So it depends on if you have enough HD space for the uncompressed Huffy, and how long the original Huffy encoding takes with all the filters. But, if you're using both PixieDust and C3D, I think it'll probably result in a considerable time savings by doing it the way you're suggesting. This is a well known method for encoding SVCDs. If you're doing 4 passes with CCE, and you're slowing the encoding process with some filters (filters nowhere near as slow as your combination), then it's often worth it to make a Huffy .avi first, and then run that through CCE. Although Huffy is uncompressed, as I understand it, it's not lossless, but I don't think you'll notice any loss in quality, particularly after using your filter combination. You might try and encode a small portion of the video first to get an idea of the relative encoding times using the two methods.

@manono Huffy is compressed, and it is almost completely lossless. The losses you get from huffy are usually in the order of rounding errors, but there are some special cases that can produce larger errors. The only time you'll get measurable errors is when you convert from RGB to YUY2 or vice versa.

cheers for your help guys, but i don't understand why it wouldn't always be quicker. surely huffyuv is pretty quick to encode and decode, so you'd almost always be doing less work, wouldn't you? because you'd also be saving time on the mpeg2 decoding, deinterlacing/IVTC and resizing that you'd have to do only once instead of twice, as well as any other filters you might use?

really? i thought it would be quick. probably still quicker than pixiedust+c3d tho. good point but it was going to take about 50 hrs (estd.) to finish one pass on my celeron 900 :scared: so i'm not too worried about that its going to be only 320x240, so think i'll give it a go. i'll let you know how i get on.

i'm not arguing or anything *bows down to superior knowledge* :) but seems to reckon its very fast, like faster than real time. am i missing something? its a pity you can't break a process's cpu time down by the dlls its using, that would be interesting. edit: and just a thought, what about using divx at 100% quality instead of the huffy?

so is huffyuv everyone's favourite lossless codec then?

update: looks like the huffy is going to be about 23 GB (3 hr movie) and run for about 40 hrs. and thats after taking the c3d call out. sheesh! :(

hmm... 40hrs for 1st only or for both passes?

there is only one pass when encoding to huffyuv ;)