[FFmpeg-devel] [PATCH] Add null video filter

[Vitor Sessak]

Michael Niedermayer wrote:
> On Sun, Oct 18, 2009 at 11:21:57PM +0200, Stefano Sabatini wrote:
>> On date Sunday 2009-10-18 22:34:39 +0200, Michael Niedermayer encoded:
>>> On Sun, Oct 18, 2009 at 12:25:41PM +0200, Stefano Sabatini wrote:
>>>> On date Thursday 2009-10-08 00:18:25 +0200, Michael Niedermayer encoded:
>> [...]
>>>>> probably ok if extensively tested (for example benchmarks that it does not
>>>>> cause slowdown which would be an indication of extra memcpy being done
>>>>> somewhere)
>>>> With ffplay I didn't noticed significant slowdowns even with an insane
>>>> number of null filters (256).
>>>>
>>>> But I noticed some slowdowns with ffmpeg, even with a relatively small
>>>> number of null filters:
>>>> 16:  utime=4.876s
>>>> 17:  utime=6.368s
>>>> 18:  utime=9.501s
>>>> 19:  utime=15.745s
>>>> 20:  utime=28.246s
>>>> 21:  utime=53.067s
>>>>
>>>> With 32 null filters the process seems to hangs, a quick inspection
>>>> with gdb revealed that the processing hangs in avfilter_poll_frame(),
>>>> anyway since the problem is not related to the present filter I
>>>> committed.
>>> please elaborate
>>> what did you test, if not what was be commited?
>> With ffplay:
>> ffplay in.avi -vfilters "null,null,null,...,null"
>>
>> With ffmpeg:
>> ffmpeg -t 5 -i in.avi -vfilters "null,null,null,...,null" -y out.avi
>>
>> Note that even changing the filter (e.g. using vflip) I got the same
>> behavior, so I concluded that the problem was not depending on the
>> null filter.
> 
> the commit of the null filter made the bug possible, so it is dependant
> on it. IMHO it should not have been commited
> 
> 
> either way a chain of null filters should not cause such exponential
> slowdown, that is a very serious bug and i really think that should be
> fixed before commiting more code. If not even reverting the null filter
> commit.

I took the liberty of committing a trivial patch fixing this bug.

-Vitor