[FFmpeg-devel] [RFC] Filters and encoding commandline options interaction
Tue Feb 15 12:48:11 CET 2011
* Michael Niedermayer on Monday, February 14, 2011 at 23:16:00 +0100
> 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
While the version @videolan offers definite improvements - thank
you! -, from a poor _user_'s perspective the interaction between
-vf and -aspect and -s is utterly obscure and confusing,
especially when the source has non-square pixels (eg. vob,
pal-dv). I tried to note some of my findings at
It was marked solved and closed, but, again from user's
perspective, this feels almost like a joke. Add to it that the 2
heads of the ffmpeg hydra now also _behave_ differently, "solved
and closed" is, errmh ...
Was hei?t hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
free movies --->>> http://www.blacktrash.org/underdogma
More information about the ffmpeg-devel