Le nonidi 9 nivôse, an CCXXV, Michael Niedermayer a écrit : > maybe the enabledness value should be returned by the function (too)
It does not seem very useful at first glance, but I may be missing something. > how does this work with multiple inlinks ? > (dstctx / dstctx->enable / dstctx->is_disabled would be the same) Currently, if I read the code correctly, only filters with a single input support timeline enable/disable. In fact, I do not see how timeline could make sense for a filter with several inputs. "Disabling" a filter means replacing it by the pass-through filter "null", but it has a single input and output. > Also whats your oppinion about calling this > ff_inlink_evaluate_timeline_at_frame > or > ff_inlink_evaluate_timeline_at > ? I have no strong feeling about it one way or the other, I just find the symmetry ff_inlink_process_timeline() / ff_inlink_process_commands() nice. I have addressed your remarks about the documentation in my work tree. I do not think it is worth sending the whole series again just for that, but here are the docs in case they make understanding the rest easier. It repeats a bit what is explained in the new doxy for activate(). Note that I also changed ff_inlink_acknowledge_status() to return the link's timestamp, currently ignored but will be useful soon (vf_fps typically), and it avoids filters accessing the link directly (better for threading later). Also note that they are referring to the activate callback before it is introduced. I can move the "lavfi: add AVFilter.activate" before if it is a concern. /** * Mark a filter ready and schedule it for activation. * * This is automatically done when something happens to the filter (queued * frame, status change, request on output). * Filters implementing the activate callback can call it directly to * perform one more round of processing later. * It is also useful for filters reacting to external or asynchronous * events. */ void ff_filter_set_ready(AVFilterContext *filter, unsigned priority); /** * Test and acknowledge the change of status on the link. * * Status means EOF or an error condition; a change from the normal (0) * status to a non-zero status can be queued in a filter's input link, it * becomes relevant after the frames queued in the link's FIFO are * processed. This function tests if frames are still queued and if a queued * status change has not yet been processed. In that case it performs basic * treatment (updating the link's timestamp) and returns a positive value to * let the filter do its own treatments (flushing...). * * Filters implementing the activate callback should call this function when * they think it might succeed (usually after checking unsuccessfully for a * queued frame). * Filters implementing the filter_frame and request_frame callbacks do not * need to call that since the same treatment happens in ff_filter_frame(). * * @param[out] rstatus new or current status * @param[out] rpts current timestamp of the link in link time base * @return >0 if status changed, <0 if status already acked, 0 otherwise */ int ff_inlink_acknowledge_status(AVFilterLink *link, int *rstatus, int64_t *rpts); Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
