[FFmpeg-devel] [PATCH 06/17] lavfi: add ff_inlink_process_timeline().

[Nicolas George]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161230/79f66520/attachment.sig>