[FFmpeg-devel] expert needed (will pay $$$) to help decompose ffmpeg.c into seperate runnable tasks

Stuart Smith stuartmartinsmith
Fri Jul 24 22:23:39 CEST 2009


Hi, apologies if this is not the correct way to contact developers but maybe
you can help me.

 

We have developed a set of multithreading tools that we are trying to
show-case by demonstrating 'proofs of concept' in several different
application areas. Our domain to date has been Sonar applications but we are
keen to explore new avenues.

 

One of the areas we are interested in is video decoding & encoding. Our aim
is to try to harness some of the ffmpeg.c code (or equivalent) into our
threading platform to show a performance gain (hopefully) so we don't want
to use the multi-threaded versions of libav*.

 

What we are trying to do is to process a number of different input files (of
different types) and encode them into several different
formats/resolutions/bitrates etc at the same time (we have an 8 core machine
in the office). In effect, we are looking for single threaded versions of
code functions that will read the frames from a file, decode the frames and
encode the frames in separate threads. We will take care of spawning the
threads, data buffering/locking/sharing, synchronisation etc but we require
the functional code to be re-entrant so that we can embed it in our
'threading framework' for scheduling and execution.

 

Our threading tools should schedule the encoding/decoding tasks optimally to
get the best load balancing and CPU utilization so we don't care if the task
sizes are irregular (at least that's the plan).

 

I don't understand the processing workflow or thread safety issue of the
libav* libraries well enough so it's probably better to call in an expert.

 

It doesn't have to be the best implementation in the world as it is for demo
purposes but it should at least do what it says on the tin.

 

Does any code like this exist? 

 

If not, would anyone be interested in developing this further (there are a
few bucks available for this task but not enough to retire on :-) )

 

Cheers,

 

Stuart

 

 




More information about the ffmpeg-devel mailing list