[FFmpeg-devel] Evolution of lavfi's design and API

Paul B Mahol onemda at gmail.com
Wed May 2 12:58:17 EEST 2018

On 9/11/16, Paul B Mahol <onemda at gmail.com> wrote:
> On 9/10/16, Nicolas George <george at nsup.org> wrote:
>> Le quartidi 24 fructidor, an CCXXIV, Paul B Mahol a ecrit :
>>> So everybody agrees, we should proceed.
>> I am proceeding, but as you can see in the patch, there is still a fair
>> amount of work to be done. Still, people can help if they want to speed
>> things up, especially since a significant part of the work is design
>> decisions that I can not do alone and will need to be discussed.
>> What needs to be done (using this mail as a notepad, but including the
>> tasks
>> where help is required):
>> - Finish documenting the scheduling and make sure the implementation
>> matches
>>   the documentation.
>> - Discuss if "private_fields.h" is acceptable or decide another solution.
>> - Clearly identify and isolate the parts of the scheduling that are
>> needed
>>   only for request_frame()/request_frame() compatibility.
>> - Decide exactly what parts of the scheduling are the responsibility of
>>   filters (possibly in the compatibility activate function) and what
>> parts
>>   are handled by the framework.
>> - Think ahead about threading and use wrapper to access fields that will
>>   require locking or synchronization.
>> - Think about features whose need I realized while trying to get it
>> working:
>>   distinguish productive / processing activation, synchronize several
>> filter
>>   graphs.
>> Please feel free to ask details about any of these points: not only would
>> getting interest help me stay motivated, but discussing implementation
>> details and explaining the design would help me having a clear idea of
>> the
>> whole system.
> For start removal of recursiveness is mostly I'm interested in.
> What needs to be done for that, can I help somehow?


So what's remain to be done to have frame threading in lavfi?

More information about the ffmpeg-devel mailing list