[FFmpeg-devel] [PATCH] ffmpeg: Associate output streams with the first stream of a complex filtergraph
george at nsup.org
Sat Nov 9 10:45:23 CET 2013
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)
> - if (fg->nb_inputs != 1)
> + if (fg->nb_inputs < 1 || fg->inputs->ist->dec->type != ofilter->ost->enc->type)
> for (k = nb_input_streams-1; k >= 0 ; k--)
> if (fg->inputs->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 'overlay' is changed to
'scale=w:h[o];[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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the ffmpeg-devel