<div class="gmail_quote">2009/5/29 Piers O'Hanlon <span dir="ltr"><<a href="mailto:p.ohanlon@cs.ucl.ac.uk">p.ohanlon@cs.ucl.ac.uk</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Andrew,<br>
<br>
Sorry I didn't chip in earlier. As Leon mentions both ffmpeg and x264<br>
are designed with [multi]threading in mind. X264 will attempt to auto<br>
detect threading support when ./configure is run and on Linux and OSX<br>
it just picks up the threading support and uses it (the versions<br>
available should be using threading for x264. </blockquote><div><br>Meaning that h.264 encoding should already be multithreaded in existing versions of vic on linux? I'm not sure if I've actually observed that happening in practice - I'll have to experiment more.<br>
<br>BTW, Doug - you mentioned improved h264 performance in another email - does that mean it's more comparable to the performance of mpeg4 encoding? If multithreading is easier or better at all in 264, and if the baseline performance is better, then that might be the new standard to use.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I agree, and usually we have tested for specific/required number of<br>
threads being supported by a given codec at runtime (e.g. when user<br>
wants to have a certain number of threads associated with processing<br>
the image -- as it makes no sense to have more heavy-active threads<br>
than available cores/cpus... where the in/out scheduling of threads<br>
will only make things worse [slower/longer and w/o any advantages])...<br>
there are limitations to how effectively this could be arranged, but<br>
the simple way would be to look at the code in LavcCodec.tpp:<br><br>
...<br>
if (threads && -1 == avcodec_thread_init (&context, threads))<br>
cerr << ERRORINFO << "could not create " << threads << " additional<br>
threads during allocation of codec... shall proceed without<br>
threads..." << endl;<br><br>
assert (assertInvariants ());<br>
return true;<br>
...</blockquote><div><br>Thanks - I'll check this out and see if I can incorporate it into UCL mpeg4 vic. Plus, the Linux support for Blackmagic cards is supposedly coming out this month, so that should be a good test for multithreading - once the grabber code is written. Doug, were you planning to do that? I'd like to contribute to that if at all possible; we do have a number of Intensity Pro cards we can test with.<br>
<br>--Andrew<br></div>
</div></div>