[Sumover-dev] Re: Possibility of merging vic features / multithreadedness

[Douglas Kosovic]

Hi Andrew,

>> Sorry I didn't chip in earlier. As Leon mentions both ffmpeg and x264
>> are designed with [multi]threading in mind. X264 will attempt to auto
>> detect threading support when ./configure is run and on Linux and OSX
>> it just picks up the threading support and uses it (the versions
>> available should be using threading for x264.
> 
> 
> 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.
> 
> 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.

That was regarding newer x264 codec performance being faster than the 2 
or 3 year old version of x264 used with previous builds of vic. I don't 
have firsthand comparison between the newer x264 and ffmpeg 0.5's mpeg4.

> I agree, and usually we have tested for specific/required number of
>> threads being supported by a given codec at runtime (e.g. when user
>> wants to have a certain number of threads associated with processing
>> the image -- as it makes no sense to have more heavy-active threads
>> than available cores/cpus... where the in/out scheduling of threads
>> will only make things worse [slower/longer and w/o any advantages])...
>> there are limitations to how effectively this could be arranged, but
>> the simple way would be to look at the code in LavcCodec.tpp:
>>
>> ...
>> if (threads && -1 == avcodec_thread_init (&context, threads))
>>   cerr << ERRORINFO << "could not create " << threads << " additional
>> threads during     allocation of codec... shall proceed without
>> threads..." << endl;
>>
>>   assert (assertInvariants ());
>>   return true;
>> ...
> 
> 
> 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.

I was planing on adding V4L2 VIC support for the Blackmagic card, as I'm 
away all next week I was hoping the driver would have been released by now.


Cheers,
Doug