[MPlayer-users] Single threaded mencoder on a Dual Core machine
Corey Hickey
bugfood-ml at fatooh.org
Sun Apr 23 19:21:02 CEST 2006
Rich Felker wrote:
> On Wed, Apr 19, 2006 at 09:56:04PM +0200, Reimar Döffinger wrote:
>> Hi,
>> 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.
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.
* 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.
-Corey
More information about the MPlayer-users
mailing list