Multi Output Encodings

[Kaiousama]

Often, during the xvid build tests, and during the new avisynth filters' tests, i have to make some versions of the same clip encoded i.e. at a progressive quantitizer i.e. one file at q2 one at q3 with the same settings etc etc). Nowadays i have to make n encodings of the same clip.

What about the implementation of a multi output encoding process in XviD that lets you the possibility to do one encoding and to create n files each one with i.e. an increased quantitizer value, all this saving time because the codec does the motion estimation calculations and all the others only one time for the encodings train and then when it compress and store the frame, it uses this informations to store 2 frames on 2 different files encode with different quant?

What do you think about? could it be useful/implmementable?

Best regards

[jonny]

Funny, i was thinking at something similar in those days :)
AFAIK there are some problems, because this will require both modifications to the XviD codec and VirtualDub.
A solution could be modifying only the codec packing the frames together in a single avi file (but this will require an external app that "demux" the frames to create a playable avi).
I don't have idea of what the level of complication this thing could add to the codec...

[sysKin]

I wouldn't count on sharing any coding step - motion estimation, for example, _is_ dependant on quantizer, as well as on reference picture (which is dependant on its quantizer again).

So, you could just modify encoding application (vdub) to take one frame and send it to two instances of encoder. Two XviDs should run in parallel without any problems. You would save time on filters and colorspace conversions.

Radek

[jonny]

The idea is really interesting.

Are you able to give an approximation of the % of time used for frameserving (for example an mpeg2 source with crop/resize only) versus % of time to actually encode?

Supposing that i'm going to mix different parts of 2 qb encodes (joining at keyframes, of course), this could cause problems to the end stream?

Last question... qb encoding with different quants could result in a different keyframe allocation, isn't it?

Sorry for all those questions :)