An idea for decomb

Could decomb be made to output all the decisions that it makes into a file, so that when you are doing multiple encodes of something, it will only have to make the calculations one time? I was just thinking of some of the possibilities with that sort of feature. I would imagine that the 2nd+ encodes would be faster. Also it could be possible for someone to write a tool where you can go in and eaily fix areas that didn't IVTC properly, like you can do in tmpgenc.

I've suggested this before and it was concluded that the act of writing to and reading from a file actually slows down the process sufficiently to actually outwiegh any gains in processing speed.

Really? :eek: Oh well, I guess my ideas always just suck then :p

I was thinking if you have enough space, why not first encode it to huffyuv and rencode from that?

I think trbarry gets the "Wisest Doom9'er Award". That is, of course, 'wise' in the sense of 'wisdom', not in the sense of 'wise guy'. :)

Actually this may not be as silly as it sounds, sure it doesnt suit telecide and fielddeinterlace but it would suit decimate. Decimate in mode 1 or 2 takes a fair bit of cpu time, a cache file for these could help a lot. For mode=1 all it needs is framex and the value it got for it (then it'd be simple enough to try other thresholds, or just the frame and blend/pass if you wanted to make it so thresholds couldnt be changed) For mode=2 the simplest would just be the frame#'s to drop, or list all the motion in each frame so the cycle can be changed without recaching. If I dont understand something of this let me know but as i see it it'd be quite useful in decimate.

@gamr What you don't understand from the other threads is that I have already decided not to do it. :D