[MPlayer-users] Single threaded mencoder on a Dual Core machine

[Loren Merritt]

On Sun, 23 Apr 2006, Corey Hickey wrote:
> Rich Felker wrote:
>> On Wed, Apr 19, 2006 at 09:56:04PM +0200, Reimar Döffinger wrote:
>>> On Wed, Apr 19, 2006 at 11:03:35AM -0700, Corey Hickey wrote:
>>>> will give you 2x performance on a dual core machine. The only way to do 
>>>> that is to have two encoders working on separate files -- each file takes 
>>>> just as long as before, but you can encode twice as many.
>>> Although difficult, this means it is also possible to split a file up,
>>> encode it and then concatenate it again. No idea if anyone got this to
>> 
>> This defeats the whole purpose of 2pass quality optimization.
>
> Yes, at least as far as things are now. In order for that to work properly, 
> the encoder would have to be aware that it is working on a chunk and know the 
> statistics for the whole file. Something like:
>
> 1. Split source file into chunks.
> 2. Encode chunks separately, first pass.
> 3. Gather and concatenate the two-pass statistics.
> 4. Encode chunks again, second pass. The encoder of each chunk must:
>   a. Have the entire divx2pass.log
>   b. Know (or be provided) the position of the chunk it's working on.
>   c. From the data above, encode the chunk just as if it were in the
>      middle of encoding the while file.
>
> That seems possible to me, unless I'm missing something. I don't really have 
> the time to try to implement anything, though.

And guess what? It's been done.
http://www.funknmary.de/bergdichter/projekte/index.php?page=ELDER

> A file encoded using that method wouldn't be identical to a normal encode, 
> for two reasons:
>
> * The divx2pass.log would be a bit different. With reasonably large chunks, 
> this shouldn't be a problem because the average bitrate for that chunk won't 
> be wildly different from the global average bitrate.

True for ABR. CBR 1st pass is pretty close, and quality-based 1st pass is 
identical.

> * Frame types wouldn't be the same, since each chunk would have to start with 
> an I-frame and end with at least a P-frame. With reasonably large chunk 
> sizes, the difference should be negligible.

That's fixable: discard frames from the beginning of a chunk until you get 
to the first real I-frame, and encode them in the previous chunk instead.
Or just re-encode the I-frame, and ignore slight differences in 2pass 
stats for the rest of that gop.

--Loren Merritt