[XviD-devel] multithreading

[Lars Täuber]

Hi Michael,

On Thu, 25 Jun 2009 16:37:07 +0200 Michael Militzer <michael at xvid.org> wrote:
> Your idea with the 2-pass stats works too: You could split the input stream
> in e.g. four parts, run four xvid encoder instances in parallel that do the
> first-pass. You then end up with four first-pass stat files. Your app
> then joins the stat files and analyzes the relative complexity of each of
> the sub-parts. According to that analysis you assign target bitrates or
> filesizes to each of the four parts, launch four xvid encoder instances in
> second-pass mode and again join everything together in the end.
> 
> I remember that this idea had already been discussed in the past, so there
> should be some tool already that can do this for you. In any case, this
> method should give good quality (as long as you don't partition the input
> into too many small pieces), scales well, will be fast and really easy to
> implement (on the application level).

this is not exactly my idea but near.

I'd like Xvid to go through the video in a 1st run and tell the application the series/order of frames types.
Then the application could split the video depending on the now known GOP borders into pieces containing exactly the frames used for the new GOPs. Then it could run as many parallel encoding processes as it likes given enough pieces are available.
(or pairs of threads: decoder => encoder)

This will only work efficiently when all the new GOPs are independently encodable. As far as I know this is the case with xvid right?
Of course this is only meant for quantized encoding without any bounds for the bitrate.

Is this possible?

Thanks
Lars