Le decadi 30 brumaire, an CCXXIV, Clement Boesch a écrit :
> 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);
> }
Indeed. Note: you may want to keep both "in->out" and "out->in" maps in
arrays.
> 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).
If the corresponding input is connected to a buffersrc fed from a file, that
is perfectly normal.
> 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?
I had not thought about this issue before now. I think it is not possible in
principle. Consider this graph:
+-----------+
[v1] ---->|----. | +--------+
| `---->|---->[ setpts ×2 ]---->| |
[v2] ---->| | | vstack |---->
| .---->|---------------------->| |
[v3] ---->|----´ | +--------+
+-----------+
With the ×2 setpts, v1 must be consumed twice as fast as v3 (or the other
way around, does not matter). But then, what happens when v2 gets connected
to one of the outputs?
You need to decide the constraints or the user interface to solve this
before you can implement anything.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
