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

[Stuart Smith]

Hi Stefan, our threading toolset is designed to describe and manage
extremely complex systems - that is our forte. We have been handling systems
that detect, track and classify military threats in real-time so we have
that (complex software) angle covered.

We just don't know anything about video decoding/encoding but obviously
there are a large number of people in these lists who do.

We do not want anyone to write multi-threaded code for us, we just want the
processing to be de-composed into a series of independent tasks that we will
schedule and co-ordinate and make best use of the hardware.

Although I don't fully understand the whole decoding/encoding process I
believe that we want some discrete (and thread-safe) functions that read a
file and return a data packet, a function that decodes a packet and returns
a decoded frame and a function that encodes a frame. This needs to be
repeated for both the audio and video frames. The outputs from these
functions will then be passed to another function that syncs the frames to
generate the output.

I may be oversimplifying the workflow but I don't want anyone to consider
spawning threads, joining threads, buffering data, locking/sharing data,
synchronizing the threads or anything that involves mutexes, semaphores etc.


The whole point of this exercise is to show our framework co-ordinating and
scheduling the tasks in the best possible way (and creating new processes to
do the work just takes up too many cycles compared to the efficient use of a
thread pool).

If anyone can help in any way it would be appreciated.

Cheers,
Stuart

-----Original Message-----
From: ffmpeg-devel-bounces at mplayerhq.hu
[mailto:ffmpeg-devel-bounces at mplayerhq.hu] On Behalf Of Stefan de Konink
Sent: 24 July 2009 22:51
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] expert needed (will pay $$$) to help
decomposeffmpeg.c into seperate runnable tasks

On Fri, 24 Jul 2009, Vladimir Pantelic wrote:

> yes, but then just run every encode in its own process, why the threads
> if you don't want them?

I think you should read exactly what he writes. He probably wants to
streamline the process. So a dedicated system for each encoding step, and
optimise that with resources.

This indeed could give a performance++, but it gets rather complex. Maybe
this complexity is much a smaller amount of $$$ than the hardware that is
used for the task.


Stefan

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel