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

Vitor Sessak vitor1001
Mon Oct 19 14:46:01 CEST 2009


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] :)

-Vitor

[1] 
http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2009-October/025030.html



More information about the ffmpeg-devel mailing list