[FFmpeg-devel] [PATCH] documentation: Fix several documentation bugs in trac ticket #2413

[littlebat]

On Tue, 9 Apr 2013 01:12:44 +0200
Stefano Sabatini <stefasab at gmail.com> wrote:

> On date Saturday 2013-04-06 10:01:05 +0800, littlebat encoded:
> > On Sat, 6 Apr 2013 01:59:19 +0200
> > Stefano Sabatini <stefasab at gmail.com> wrote:
> > 
> > > On date Friday 2013-04-05 21:58:09 +0800, littlebat encoded:
> > > > On Fri, 5 Apr 2013 12:40:40 +0200
> > > > Stefano Sabatini <stefasab at gmail.com> wrote:
> > > [...] 
> > > > /opt/ffmpeggit/bin/ffmpeg -i in.avi -vf \
> > > >   "movie=logo.png [logo]; [out] [logo] overlay [in_0]" out.avi
> > > > 
> > > > It seems the input video stream linked [out] automatically, and
> > > > the command line works well! I suppose these two special links
> > > > "[in]" and "[out]" have been dropped in the current ffmpeg, or
> > > > they don't function properly if they are still designed as
> > > > special labels. 
> > > 
> > > Interesting:
> > > ffmpeg -i INPUT -vf  "movie=ffmpeg-logo.png [logo]; [foo][logo]
> > > overlay [bar]" -y OUTPUT
> > > 
> > > Looks like if there is an unconnected filter input it is
> > > connected to the default filter output, and the unconnected
> > > filter output is connected to the default filter input. This was
> > > the result of some relatively recent work on -filter_complex, but
> > > seems more like an (undocumented) glitch rather than a feature.
> > > 
> > > The equivalent command fails with ffplay:
> > > ffplay INPUT -vf  "movie=ffmpeg-logo.png [logo]; [foo][logo]
> > > overlay [bar]" [...]
> > > Output pad "default" with type video of the filter instance
> > > "ffplay_buffer" of buffer not connected to any destination
> > 
> 
> > I see, "[in]" and "[out]" are still designed as the special labels
> > in the entire ffmpeg system. Using them is not harmful, but,
> > lacking them, some times, will cause problem, as your ffplay
> > example above. My understanding is ok? 
> 
> Not in the entire FFmpeg system, they still are in ffplay -af/-vf,
> while -filter_complex has an entirely different syntax. ffmpeg -af/-vf
> has glitches, which are possible unwanted effects of the recent
> changes in the code (can't say since I'm not the author of the code,
> which didn't updated the docs).
> 
> > 
> > >diff --git a/doc/filters.texi b/doc/filters.texi
> > >index 483d8a1..773657f 100644
> > >--- a/doc/filters.texi
> > >+++ b/doc/filters.texi
> > >@@ -5,8 +5,8 @@ Filtering in FFmpeg is enabled through the
> > >libavfilter library. 
> > > In libavfilter, it is possible for filters to have multiple
> > > inputs and multiple outputs.
> > >-To illustrate the sorts of things that are possible, we can
> > >-use a complex filtergraph. For example, the following one:
> > >+To illustrate the sorts of things that are possible, we consider
> > >+the following filtergraph.
> > 
> > I found you still reserve the sentense "
> >  In libavfilter, it is possible for filters to have multiple inputs
> > and multiple outputs.", but, the example here is just one video
> > stream in and out, so, is this sentense a harmful influence on your
> > example? Is it better to delete this redundant sentense? Or, add
> > some thing to indicate this? for example, like below:
> >  In libavfilter, it is possible for filters to have multiple inputs
> > and multiple outputs.
> >  To illustrate the sorts of things that are possible, we consider
> >  the following filtergraph(this filtergraph has only one input and
> > output stream).
> 
> You're confusing filtergraphs and filters, in the example we have a
> *filtergraph* with one input and one output, but there is a filter
> with two outputs (split) and a filter with two inputs (overlay).
> 
> Since yours is a possible interpretation of the text, I tried to tweak
> that in order to remove the confusion. Patch updated.
> -- 
> FFmpeg = Fantastic and Fiendish Mournful Portable Embarassing God

>...
>-In libavfilter, it is possible for filters to have multiple inputs and
>-multiple outputs.
>-To illustrate the sorts of things that are possible, we can
>-use a complex filtergraph. For example, the following one:
>+In libavfilter, a filter can have multiple inputs and multiple
>+outputs.

If no any filter can have multiple inputs and multiple outputs at the
same time, I think, "a filter can have multiple inputs *or* multiple
outputs" should be more accurate.