[FFmpeg-devel] [PATCH 06/17] lavfi: add ff_inlink_process_timeline().
george at nsup.org
Fri Dec 30 13:37:41 EET 2016
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
> 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
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()
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
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);
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel