[FFmpeg-devel] Evolution of lavfi's design and API
Paul B Mahol
onemda at gmail.com
Sat Jun 2 19:38:38 EEST 2018
On 5/2/18, Paul B Mahol <onemda at gmail.com> wrote:
> 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
>>> where help is required):
>>> - Finish documenting the scheduling and make sure the implementation
>>> the documentation.
>>> - Discuss if "private_fields.h" is acceptable or decide another
>>> - Clearly identify and isolate the parts of the scheduling that are
>>> 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
>>> 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
>>> distinguish productive / processing activation, synchronize several
>>> Please feel free to ask details about any of these points: not only
>>> getting interest help me stay motivated, but discussing implementation
>>> details and explaining the design would help me having a clear idea of
>>> 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