Interesting thought for multi-pass encoding

[cogman]

I have been encoding for a little bit with Xvid now and sometimes just wish I could make things go faster.

Well, Threading helps, but it does not always give a really big boost in speed, nor does it always use all the potential power of the CPU. So I was think, Why not vary first and second pass encoding time on different thread?

I've noticed that the first pass is almost always faster then the second pass, so would it be possible to just start the first pass on the information thats currently being chucked out by the second pass? Currently I have mencoder and DVDFab, I know I can't do it with DVDFab but would such a thing be possible with mencoder? Thanks for the Ideas.

[Soulhunter]

Uhm, doesnt the 2nd pass need a complete 1st pass log to make its calculations?


Bye

[cogman]

Yeah, your right, guess thats what I get for thinking im clever :). I guess a single pass encode is basically what I have described but the obvious result is a lower quality of encode.:thanks:

[blizard]

We all wish it could go faster, but I think Cogman also forget to see that there is more to this then CPU calculation. It is also how fast storage capacity (harddisk) can work and from my understanding it was also the main purpose of multi-pass (or two pass) encoding to find out an upper limit for storage to fit a movie on one CD (around 700 MB) with the best bit rate for each frame and evenly distribute resources so action scene wouldn't look bad compared to more scene with darker area etc. That is why first pass encoding can go faster as it make an estimate for each frame are to be encoded later. It will need also to know the size of sound stream which is processed before or during this process to calculate storage size and then what bit rate that would be set by encoder.

Multi-threading these processes would need parallel processing and when both sound stream and video stream are calling for the same operation, what would then happen?

Today's harddisk work at 7200 RPM in most computer and this would also be a limit for how many parallel processes that can be done at the same time. Reading sound stream, reading video, reading subtitle and then process all this at the same time with intermediate storage, and in the end write all these stream into one container means many move on harddisk head. I am aware there is Raptor and other harddisk, but hey are still very expensive compared to mainstream 7200 RPM.

I would think that this would need another type of cooperation between different project to get all kind of stream (video, sound and subtitle at least), that can fit into one container of any kind to be processed in a way that isn't easy to make real without change how it is done today.

You can mix from different open source project (Xvid;libavcodec etc) and build application without being limit to some person or some organisation that fail to deliver their code in time. With parallel processing this would be the opposite and force new way of cooperation between different project. It would make dependent a codec for sound, with codec for video and so on, to get the optimal parallel process in multi-threading.

That is what I believe, but I could might wrong on this. ;-)