An idea for decomb

[Zarxrax]

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.

[zettai]

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.

[Zarxrax]

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

[trbarry]

Oh well, I guess my ideas always just suck then

As ideas go, it is a very good one and you should keep suggesting them. Always!

But sometimes there is a tradeoff between the cost of different components that is hard to judge. And in this case I concurr with Neuron2 that it would be a lot of work for very little gain.

I am an idea person myself. I toss out lots of ideas on this board and a couple others. Some of them turn out to be good ideas and some turn out to be pretty incredibly silly.

But if I never allowed myself to even mention them then none would ever get implemented. And even the really stupid ones I mention are sometimes fixable if I get a whole bunch of smart people interested in solving the problem.

That's one of the nifty things about places like this.

- Tom

[Aktan]

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

[Belgabor]

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


Same reasoning. This works out for smaller files with heavy filtering (aka worked well for my 20 min anime tv caps), but any possible speed gain could be offset for the time needed to write the huge huffyuv file with long things like dvd rips.

Cheers
Belgabor

[Guest]

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'. :)

[gamr]

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.

[Guest]

@gamr

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