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

Christian Iversen chrivers
Mon Oct 19 17:49:45 CEST 2009


On 2009-10-19 14:46, Vitor Sessak wrote:
> Christian Iversen wrote:
>> On 2009-10-19 00:34, Vitor Sessak wrote:
>>> 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.
>>
>> Might we know what that patch consisted of? I'm sure several people
>> are dying to know :)
>
> I could tell, but people will see (and flame me) in ffmpeg-cvslogs list
> anyway [1] :)

Ouch, that's kind of like people saying recursion is slow because it 
takes ages to compute fib(n)... ;-)

-- 
Med venlig hilsen
Christian Iversen



More information about the ffmpeg-devel mailing list