[theora-dev] Multi-Thread Theora Encoder

[Maik Merten]

Nice work. Too bad I'm still on a single-core system (but now I have a
nice excuse to mothball this system and go ahead assembling a new one).

Two things I noticed:

 - output bitrate seems to vary slightly depending on how many threads
are used (no visible difference, though). If your goal for the
optimization is to have it produce exactly the same output and you're
thinking right now "wait, this shouldn't happen" then there may perhaps
be a problem in the new code.

 - the example encoder segfaults using an excessive number of threads
(for me 382 threads seems to be the maximum number of threads still
working on my CIF input file). For some reason my gdb doesn't work on
encoder_example ("not in executable format: File format not recognized"
- huh?) so I can't really say where things are going wrong (may e.g. be
a system lib doing strange stuff and not your code).


Maik


Felipe Portavales Goldstein schrieb:
> I uploaded the changes to the branch:
> http://svn.xiph.org/branches/theora-multithread/
> 
> This version is a branch from the current SVN trunk.
> I used the theora_control to set the number of threads as Giles sugested.
> 
> to run the example you can specify the number of threads with the flag
> --number-of-threads
> 
> For example:
> 
> ./encoder_example --number-of-threads 1 ~/video-tests/pf01.yuv -o
> /tmp/thread.ogg
> 
> 
> Please,
> Test in different machines and with different videos.
> 
> 
> Cheers,
> Felipe
> 
> 
> On 10/3/07, Ralph Giles <giles at xiph.org> wrote:
>> On Wed, Oct 03, 2007 at 12:57:59AM -0300, Felipe Portavales Goldstein wrote:
>>
>>> As far as I tested the slowdown is less than 1 percent or irrelevant.
>> Good, we should be able to include this in the mainline then.
>>
>>> The only big difference in terms of performance is the extra-overhead
>>> in the PickModes function call and a extra final loop to re-order the
>>> Motion Vectors produced by each thread.
>> So this overhead can be skipped when there's only one thread.
>>
>>> The only thing that I should do before submit is a way to control the
>>> number of threads at run time (discover the number of CPUs at run
>>> time). By now I have to recompile the code to have a different number
>>> of threads running.
>> The best way to do this is through the theora_control() interface, since
>> applications will want control, and determining the number of available
>> CPUs is very platform dependent.
>>
>>  -r
>>
> 
>