On Thu, Nov 19, 2015 at 06:47:07PM +0100, Nicolas George wrote: > Le nonidi 29 brumaire, an CCXXIV, Clement Boesch a écrit : > > - I always receive frames from the first input link... I suppose I need > > to write a "smart" request_frame callback, but things changed recently > > so maybe there are new guidelines for this? Nicolas, can I call for > > your help again? > > Nothing new except you do not have to loop: just forward the request on the > output to the connected input. But you have to decide what to do when an > output is not connected to any input; EAGAIN comes to mind, but I am not > entirely sure it will work correctly. For now I would suggest to make it > unsupported: either an input is connected or it is EOF. >
Alright, so if I understand well, all I have to do is implement a
forwarding such as this:
static int request_frame(AVFilterLink *outlink)
{
AVFilterContext *ctx = outlink->src;
StreamSelectContext *s = ctx->priv;
const int outlink_idx = FF_OUTLINK_IDX(outlink);
const int inlink_idx = s->map[outlink_idx];
AVFilterLink *inlink = ctx->inputs[inlink_idx];
return ff_request_frame(inlink);
}
Which indeed seems to do the trick when set for to every output pad
request_frame callback.
Unfortunately, it seems the other stream(s) in "background" (not present
in the mapping) will not be consumed at all (filter_frame() is not called)
so frames are never dropped. As a result, when switching to that
background stream, the frames are delayed by a large margin (the amount of
time the main stream has been in use).
While I still need to add a timing check in the context (to avoid small
non monotonically problems), how would it be possible to continue
consuming the background streams?
--
Clément B.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
