On 9/10/16, Nicolas George <geo...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
