[FFmpeg-devel] [PATCH] avfilter/WIP: add streamselect filter
u at pkh.me
Fri Nov 20 16:06:27 CET 2015
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];
Which indeed seems to do the trick when set for to every output pad
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel