[FFmpeg-devel] [PATCH] ffmpeg: Associate output streams with the first stream of a complex filtergraph

[Nicolas George]

Le decadi 20 vendémiaire, an CCXXII, Michael Niedermayer a écrit :
> Previously such streams where un-associated
> Fixes Ticket2969
> 
> Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> ---
>  ffmpeg.c                 |    2 +-
>  tests/ref/fate/sub2video |    1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 86b7162..62f5e63 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2110,7 +2110,7 @@ static int transcode_init(void)
>              OutputFilter *ofilter = fg->outputs[j];
>              if (ofilter->ost->source_index >= 0)
>                  continue;
> -            if (fg->nb_inputs != 1)
> +            if (fg->nb_inputs < 1 || fg->inputs[0]->ist->dec->type != ofilter->ost->enc->type)
>                  continue;
>              for (k = nb_input_streams-1; k >= 0 ; k--)
>                  if (fg->inputs[0]->ist == input_streams[k])

(The Trac ticket it addresses is already fixed another way, so my answer is
mostly theoretical; sorry for the delay.)

I believe this is a bad idea, for mostly two reasons.

First (this is rather minor) setting ost->source_index could lead to part of
the code neglecting the other inputs. It does not currently happen, but
changes using ost->source_index could happen.

Second, it is rather fragile. For example, if '[0][1]overlay' is changed to
'[1]scale=w:h[o];[0][o]overlay', the order of the graph's inputs changes,
and therefore the associated stream. This change happens for no reason the
user can guess.

If that kind of association were necessary, I believe walking the filter
graph would be necessary, instead of relying on the order of the inputs.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131109/c2bfafd9/attachment.asc>