[FFmpeg-devel] [RFC] Filters and encoding commandline options interaction
Mon Feb 14 23:16:00 CET 2011
On Mon, Feb 14, 2011 at 09:12:28PM +0100, Stefano Sabatini wrote:
> Some quote from this thread:
> On date Saturday 2011-02-05 16:27:32 +0100, Stefano Sabatini encoded:
> > New tentative approach, tested with CONFIG_AVFILTER = 1, -aspect N:D
> > -vf F, -vf F -aspect N:D, stream copy and CONFIG_AVFILTER = 0,
> > regression test passed.
> > I tried also with auto-inserting a setdar filter at the end of the
> > filterchain, but that was more complicated and I preferred to simply
> > copy the functionality of setdar to ffsink.
> > The only problematic aspect of this approach is that the interaction
> > of -vf setdar with -aspect is not very intuitive, as the value of
> > frame_aspect_ratio always overrides the value set at the end of the
> > filtergraph (even when -aspect is not specified).
> Now I have the same problem with my audio-filters branch, basically we
> need to find some way to pass the information from commands which
> affect encoding (-s, -aspect, -pix_fmt for video, -ar, -ac,
> -sample_fmt for audio).
> There are three scenarios to consider:
> * with CONFIG_AVFILTER and no-copy encoding
> * with !CONFIG_AVFILTER and no-copy encoding
> * with copy
> With copy the filterchain is not setup so the logic is unchanged.
> For example in the case of -aspect, Michael solution currently adds a
> setdar filter for setting the aspect at the end of the filterchain
> string, so it fixes the case:
> ffmpeg -i IN -vf F -aspect A OUT
> but can't work in the case:
> ffmpeg -i IN -aspect A -f VF OUT
like i said this is trivial, fixed in ffmpeg at videolan now
> as when -vf F is set the previously value set for F (with the setdar
> filter description) is wiped out.
> So the first point is to define the semantics of the above mentioned
> commands and of -vf/af.
> Let's consider this:
> ffmpeg -i IN -s WxH -vf F OUT
> We can interpret it in two distinct ways:
> 1. the output of IN is scaled to WxH, *then* F is applied.
> This is equivalent to:
> ffmpeg -i IN -vf scale=W:H,VF OUT
> 2. the output OUT must be scaled to WxH, *after* F is applied.
> This is equivalent to:
> ffmpeg -i vf F,scale=W:H
no interrest in bikesheds
> Also how should we deal with the case:
> ffmpeg -i IN -vf F1 -vf F2 OUT
> the current behavior is that when F2 is set F1 is discarded.
> Depending on the logic that we prefer we may want to keep this
> behavior (and add a warning), or make it behave like:
> -vf F1,F2
> And of course there is the much more complicated cases with more than
> one output (which is currently broken):
> ffmpeg -i -vf F1 OUT1 -vf F2 OUT2
> In this case the filterchain is set to F2, and it is applied in this
> IN --> F2 -> OUT1
> IN --> F2 -> OUT2
fixed in ffmpeg at videolan
> so if we set the size through the filterchain description the video
> injected to OUT1 and OUT2 may have different size/pix_fmt and will
> result in a corrupted stream.
> Comments are welcome.
Please send patches against ffmpeg at videolan from now on
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel